[Standards] Re: Remove requirement to send disco#info feature in XEP-0030

[Ralph Meijer]

On 11 March 2024 10:51:39 CET, Kevin Smith  wrote:
>
> [..]
>
>It seems to me that, although this has always seemed like a strange wart, the 
>fact that it might cause implementations to need to be updated (whether such 
>implementations are known of by The Internet or not), making the change is 
>inconsistent with the requirements of Final (XEP-0001) so shouldn't be made.
>
>/K

Agreed. This is a wart that we'll have to keep for hysterical raisins. 

-- 
ralphm
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

Re: [Standards] FYI: Urgent XEP published: XEP-0464

[Ralph Meijer]

Congrats! In the best of traditions, I think it would be proper to fix the date 
and track, possibly with a force push.

--
ralphm

From: Jonas Schäfer 
Sent: Friday, April 1, 2022 08:34
To: standards@xmpp.org
Subject: [Standards] FYI: Urgent XEP published: XEP-0464

> Hi all, 
>
> Editor hat on. 
>
> This announcement may seem a bit unorthodox, however, the past days, weeks, 
> months and years have seen a lot of criticism of XMPP. Often times, people 
> claim that there is a single specific feature missing which other messengers 
> have and which is absolutely required, otherwise, XMPP will be doomed. 
>
> Obviously, we cannot run after each feature such claimed. We need to be 
> smarter and find the underlying technologies which enable such features. For 
> this, we need to look no further than the Web. 
>
> The web has been a great success. Look at all the things on the web. Matrix 
> uses web technology and many other popular messengers, proprietary or libre, 
> closed or federated, are built upon technologies enabled by the web stack, 
> such as WebSockets, WebRTC, WebASM, WebGL, or WebRCE. 
>
> Since XMPP is clearly still stuck in the 90ies, we need to start our catch up 
> with a 90ies web technology which could not have been more influential. 
>
> With this introductory text, the following XEP announcement should make most 
> sense to everyone: 
>
> Version 1.0 of XEP-0464 (Cookies) has been released. 
>
> Abstract: 
> This document defines an XMPP protocol extension for setting and 
> sending cookies. 
>
> Changelog: 
> Publish initial version via fast track (XEP Editor: jsc). (tjb) 
>
> URL: https://xmpp.org/extensions/xep-0464.html 
>
> Note: The information in the XEP list at https://xmpp.org/extensions/ 
> is updated by a separate automated process and may be stale at the 
> time this email is sent. The XEP documents linked herein are up-to- 
> date. 
>
> kind regards, 
> Jonas Schäfer 
> XMPP Extensions Editor
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: PubSub events with multiple "item" and "retract" elements

[Ralph Meijer]

On 09/02/2022 16.56, Melvin Keskin wrote:

Thanks for the history!

I think that there are two main questions:

1. Should it be possible to publish or retract multiple items within
one request?
2. May event notifications contain multiple items (if batch processing
is possible or if the server caches multiple requests)?

Even if multiple items may be published or retracted within one
request, event notifications could still be sent out for each published
or retracted item. But that should be clarified by the specification.


The primary reason for the discussion to get rid of batch processing is 
the more complex error handling. E.g. what happens if you try to publish 
three items and one is not acceptable? Do all of them fail or not?


So I would do the following:

1. When publishing or retracting items, only provide one item at a time.
2. When receiving notifications, be prepared to handle multiple items.

--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: PubSub events with multiple "item" and "retract" elements

[Ralph Meijer]

On 09/02/2022 12.17, Melvin Keskin wrote:

Hi,

I am wondering why the XML schema for PubSub events (
https://xmpp.org/extensions/xep-0060.html#schemas-event) specifies that
the "items" element of events may contain multiple "item" and "retract"
elements:


   
 
   
   
 
 
   


While
https://xmpp.org/extensions/xep-0060.html#publisher-publish-request
and https://xmpp.org/extensions/xep-0060.html#publisher-delete-request
  specify that it is not allowed to publish multiple items,
https://xmpp.org/extensions/xep-0060.html#impl-batch allows that
explicitly.

I could imagine an event containing multiple items triggered after such
a batch processing or if the server caches multiple single item
publications before sending an event notification. But if that should
be possible and handled by clients, where is that specified?


Yes, the confusion is understandable. Working up to version 1.13, batch 
processing was first removed [1] and then restored [2], pending 
discussion. It seems the restoration was not complete in all places, 
including sections 7.1 and 7.2.


[1] 

[2] 



It seems to me this is an editorial oversight, and discussion didn't 
result in a final removal. It would be good to understand if 
implementations currently support batch processing, though.


I know that both Wokkel and Idavoll do support batch processing, but 
that's not significant enough to be representative for all implementations.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [Members] Feedback on the proposed CoC

[Ralph Meijer]

On 04/02/2022 11.39, Daniel Pocock wrote:


[..]

I don't understand why the CoC is being subject to a standards process.
It is a social phenomena.  In many organizations this type of thing is
part of the constitution or a very closely related document.  In such
cases no member can be censored unless they do something that is
obviously over the threshold to justify an expulsion process.  Such a
process often involves evidence and a right of reply.  The CoC
undermines the rights of members in such a case and therefore it could
be seen as a hack against the organization.


Every organization needs a process to develop policies that complement 
its bylaws. It is a long established process in the XSF that we develop 
policy documents through our XEP process, as outlined in XEP-0001. It 
provides a structured way to work on such policy documents, allowing for 
input from, and discussion between, members and non-members alike.


In no way does developing such policies this way diminish the rights of 
members. The Board may eventually decide to make a version of this 
document Active, after carefully issuing last-calls and processing 
feedback. As with any decision made by the Board, is simply part of the 
role of the Board to “manage the business and affairs of the 
Corporation”, on behalf of the membership. That is what they are elected 
to do. As always, the membership has the ultimate say and can formally 
disagree and reverse any action by the Board.


There is no hack.

Kind regards,

Ralph Meijer
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [XEP-0030] we can't get basic information on a bare JID without presence subscription

[Ralph Meijer]

On 19/01/2022 10.11, Georg Lukas wrote:

The problem is that I need to have presence subscription to do that on a bare JID (due to 
"https://xmpp.org/extensions/xep-0030.html#security;), even if the node I want 
to request (in the presence case, it's XEP-0277's microblog node) is open and thus 
publicly accessible.



I've made a pull request to update XEP-0030 at 
https://github.com/xsf/xeps/pull/1145[1] . My proposal is to remove entirely 
those considerations (but to keep ones regarding available resources).


Thanks for providing the PR. I see the rationale and the need for a
change, and I don't disagree with a backward-compatible change.

However, in the specific PR you are completely removing the
"algorithmic" description of what a server is supposed to do and which
exact replies it has to send.

Instead, I would very much welcome a PR that retains the overall
structure that you removed, and instead improves the wording of the
conditions to cover the additional use cases, like nodes with "open"
access model.


An other option could be to keep the consideration, but allow disco#info when a node is specified, 
thus one could disco#info with node "urn:xmpp:microblog:0" even without pubsub 
subscription, that would keep the "service-unavailble" when no node is specified (but I 
think this measure will become totally useless as open nodes will become more common).


If you prefer to go down this path, this would be a change to XEP-0277,
where it can just override the default "MUST NOT" behavior of 0030
without touching the text of 0030, but I really see a need to update
0030 to cover the "open" nodes.


I suppose the concept of open nodes implies that the entity (in this 
case a user's bare JID) can no longer be hidden. Then, to me the partial 
sentence “or is not otherwise trusted” applies. I.e. everyone is 
“otherwise trusted” now. A service may still choose to restrict what it 
returns in response to a disco#info request, based on the existence of a 
presence relationship. E.g. will respond with pubsub#rsm but not other 
stuff.


Given the above, potentially no changes are needed, but clarifications 
might help.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Ralph Meijer]

On 04/01/2022 18.55, Jonas Schäfer (XSF Editor) wrote:

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: PubSub Namespaces
Abstract:
This extension defines a new PubSub node attribute to specify the type
of payload.

URL: https://xmpp.org/extensions/inbox/pubsub-ns.html


I am particularly interested in answers this question in section 9:

> People seem not to want to use |pubsub#type| for this but why?!

Creating a new node config field with the same semantics doesn't seem 
like the right approach. Also, it is referenced in other specifications, 
like RFC 8600 , though I have 
no idea on how widespread its use is.


--
ralphm

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Ralph Meijer]

Hi,

I too think that MUST is too strong here, as it leaves no room for services to 
ignore or override certain values, e.g. for policy reasons. SHOULD would be 
adequate here, indicating that one should understand the full ramifications of 
deviating from the specified behavior.

--
ralphm


From: Travis Burtrum 
Sent: Wednesday, December 15, 2021 05:36
To: XMPP Standards
Subject: [Standards] Proposed XEP-0060 Changes

> Hi all,
>
> A change to XEP-0060 has been proposed: 
> https://github.com/xsf/xeps/pull/1126/files
>
> 2 out of 3 parts are editorial in nature, the one part that is a 
> potential concern takes the current sentence:
>
> > After receiving the configuration form, the owner SHOULD submit a 
> completed configuration form.
>
> And appends the following to it:
>
> > The submitted configuration form MAY contain a subset of possible 
> configuration options. In that case, the service MUST only change the 
> submitted configuration options.
>
> The concern here is that adding a MUST where one didn't exist previously 
> could make existing compliant implementations suddenly non-compliant.  I 
> believe it was said in MUC discussions that prosody follows this anyway, 
> can anyone chime in about other implementations they know about ?
>
> It was also proposed that this MUST could be changed to a SHOULD, which 
> would get around the protocol-breaking, but I'm not sure it adds a lot 
> of value, since, if you can't be sure what the service will do, then you 
> can never submit just a subset of config options and hope for the best.
>
> Any input is appreciated.
>
> Thanks much,
> Travis
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Ralph Meijer]

On June 11, 2021 10:12:31 PM GMT+02:00, Dave Cridland  wrote:
>On Fri, 11 Jun 2021 at 17:10, Kevin Smith  wrote:
>
>* "No person has any automatic right to join a chatroom, or write a XEP."
>in §3 ought to be something else, since writing a XEP doesn't need the
>XSF's permission as such.
>
>I'm not sure what this can be, but I accept that writing private extensions
>using the XEP format and publishing them independently might be considered
>"writing a XEP", and that's not within the XSF's purview.

I don't agree here. Hairsplitting below.

Yes, people are free to create XMPP extensions (lowercase), and I believe it is 
one of the better strengths that people can do so without permission from 
anyone, as long as they use namespaces in a certain way to not conflict with 
others. This is part of the distributed "DNA" of XMPP, and emphasizes that the 
XSF is just one moving part in our community and not the end all and be all of 
things XMPP.

However, I also strongly believe that using the term XEP implies that it is 
part of the XSF XEP series, and that an XMPP extension in whatever format only 
becomes a XEP when it is accepted as Experimental, becoming part of the series 
and receiving a number.

I think XEP-0001 is clear on the above and the custom of calling things in the 
inbox as proto-XEP affirms this.

-- 
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Ralph Meijer]

Thanks for your comments. I'll let Dave respond in detail, except on this:

On 11/06/2021 14.19, Sam Whited wrote:

Also a general nit picky note for the editor: all the various hyphens
should be converted to em-dashes and "a XEP" should be "an XEP" (I
thought? Maybe that's not true in all dialects but I didn't think this
is one that would change).

No. The term "XEP" is normally pronounced "zepp" [6].

[6] 


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

[Ralph Meijer]

Hi Andrew,

Thank you for your feedback.

When the XSF (then JSF) started publishing XEPs they were known as 
Jabber Enhancement Proposals. We modeled this after other organizations, 
in particular the well-known PEP series of the Python Software 
Foundation. It is explicitly the intent to include both procedural and 
protocol standards documents in this series. This is why there are 
different *types* of XEPs, or *tracks* if you will. You can read up on 
this in XEP-0001.


The fact that the expanded name is now XMPP Extension Protocol doesn't 
change that fact. Whether that change was a wise choice is debatable, 
and maybe indeed we should have used XMPP Enhancement Proposal or XSF 
Enhancement Proposal or some such. I remember there was a discussion on 
this way back when, but I haven't taken the time to look it up in our 
archives.


Including procedural documents into standards series like this is a very 
common practice. Examples include the PSF mentioned above, numerous 
Apache Software Foundation procects, and the IETF. Doing it this way 
provides us with a clear framework for developing procedures and putting 
them in force. It doesn't preclude to possibility to (also) present the 
output of such proposals in other places, like a dedicated page on the 
XSF website.


If you have suggestions on how to improve our processes, we welcome your 
constructive input. We then have clear ways to consider your 
suggestions, including proposals to include cookie recipes.


--
Cheers,

ralphm


On 11/06/2021 10.40, Andrew Nenakhov wrote:
Yet another irrelevant document masquerading as a protocol extension. I 
suggest stop using XEPs as an unsorted pile of various texts, or else 
you'll soon have cookie recipes there.
If you want some place for a CoC, just put in on a website in 
'community' section next to 'membership' page.



чт, 10 июн. 2021 г. в 21:32, Jonas Schäfer >:


Version 0.1.0 of XEP-0458 (Community Code of Conduct) has been
released.

Abstract:
This document describes the XMPP Standard Foundation's Code of Conduct

Changelog:
Accept as Experimental after unanimous approval by Board of the
ProtoXEP draft for discussion within the community. (XEP Editor (jsc))

URL: https://xmpp.org/extensions/xep-0458.html


Note: The information in the XEP list at
https://xmpp.org/extensions/ 
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards

Unsubscribe: standards-unsubscr...@xmpp.org

___



--
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss

[Ralph Meijer]

On May 30, 2021 4:35:01 AM GMT+02:00, Sam Whited  wrote:
>On Sat, May 29, 2021, at 15:40, Dave Cridland wrote:
>> > But I don't see how this is different if the discussion took
>> > place on a XSF mailing list (or even at the XSF summit). I don't
>> > remember agreeing that every idea I express on an XSF mailing
>> > list is automatically covered by the IPR policy when subscribing
>> > to the list.
>> >
>>
>> That is a whole other problem.
>
>I didn't understand this section. We're not writing an XEP, we're having
>discussions about what should happen with existing XEPs.

I think what it comes down to is adopting something similar to the IETF Note 
Well, and then providing you with the means to say it applies to unofficial 
gatherings like the one you suggested. Dave, is that where you were going?

-- 
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Renewing XSF Sponsorship for 2020

[Ralph Meijer]

Dear member of the XMPP Community,

Like every year, we are grateful that the XMPP Standards Foundation had 
several sponsors in 2019. These contributions allow the XSF to pursue 
its mission <https://xmpp.org/about/xsf/mission> to build an open 
infrastructure for real-time communication based on XMPP. We would like 
to kindly ask you to consider if your organization could sponsor the XSF 
in 2020.


Sponsorship is the primary source of funds for the XSF. Besides costs 
for running the XSF as a corporation and its (online) infrastructure, we 
spend these funds on participating in events, as well as organizing 
events like the XMPP Summit, FOSDEM, and meetups. This includes 
purchasing and transporting promotion materials (posters, stickers, 
clothing), as well as lunch at the Summit.


Your contribution also enables the XSF to sponsor travel for people, so 
they can attend such events. An example is inviting former students of 
Google's Summer of Code, as an encouragement to remain active in our 
community. For this year, we are looking into funding work on necessary 
maintenance on our infrastructure.


If you would like to be an XSF sponsor in 2020, please let us know at 
spons...@xmpp.org <mailto:spons...@xmpp.org>, along with your desired 
sponsorship level and contact details. We will then send you an invoice 
to complete the application. More information on sponsorship levels and 
benefits can be found on the sponsorship page on our website 
<https://xmpp.org/community/sponsorship.html>. Should you have any 
questions, please let us know at that same e-mail address.


Thank you for your consideration.

Kind regards,

Ralph Meijer
Chair of the XMPP Standards Foundation

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Ralph Meijer]

On 17-02-2020 14:58, Matthew Wild wrote:

[..]

> > If we have to handle the case where there is no available device to

handle the feature, what is this protocol to be used for?


I don't think there's a way that all cases can be handled perfectly.

I want to expand my original use case with video calls. Our development 
of calls was in stages: first voice calls, later video. That means that 
at a certain point, there'd be three types of clients: ones that didn't 
support calls, ones that supported voice calls, and ones that supported 
voice and video calls. It is very useful to users to know what they can 
do in this situation.


Even if your account would signal that there is a registered device that 
can handle calls, a call attempt might still fail for all kinds of 
reasons. That's fine. Knowing that there's no such potential device, 
however, is useful to know, especially in the case where they are not 
online. A client could choose to not show a button to initiate a call.


Similarly, if your contact has two devices: one capable of voice calls, 
one capable of video calls, you can offer the user to initiate a video 
call. Both would ring, and video would simply fail to be negotiated. 
This is fine, as the contact might also have chosen to only respond with 
voice, even if offered video.


In short: service discovery is a way to better inform the other party of 
possible interaction patterns. It is not a guarantee that they actually 
succeed.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Ralph Meijer]

On 17-02-2020 13:44, Matthew Wild wrote:

On Mon, 17 Feb 2020 at 12:14, Ralph Meijer  wrote:




On 17-02-2020 13:04, Matthew Wild wrote:

I really don't want to just design an account capabilities system
without some real concrete use-cases that demonstrate it's our best
option.


Ok, concrete use case from my time at VEON: calling.


I almost included this case in my initial email, but I see it as
pretty much the same as the encryption one.

Just because I signed into my account once with a client that supports
receiving calls, doesn't mean I necessarily am available to receive
calls on my account.

As a personal example, I work from home most of the time, and my
primary XMPP communication is through my laptop. My phone is very
often in flight mode or flat on days when I don't leave the house. My
primary client is poezio running in tmux over ssh. It's not getting
Jingle A/V any time soon.

In my case I don't want people to think that they can just call me
over Jingle on my work-from-home days because I signed in with a
Jingle A/V client a few days ago.


The way things currently work, if your client happens to be online at 
any given time during your work-from-home days, it already exposes this 
capability and other clients can show a widget to call you.


So I think this basically means you'd want your mobile client to not 
advertise the capabilities related to calling. CAPS was specifically 
designed such that you can relay changes in capabilities, and this seems 
one of those things you should be able to toggle. Your problem seems 
orthogonal to the things being discussed here.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Ralph Meijer]

On 17-02-2020 13:04, Matthew Wild wrote:

I really don't want to just design an account capabilities system
without some real concrete use-cases that demonstrate it's our best
option.


Ok, concrete use case from my time at VEON: calling.

In the situation where most/all of your "known devices" are mobile, the 
likelihood of them being offline at any given time approaches 1. If only 
because the increasingly strict battery-saving measures in mobile 
operating systems.


I would still like to know if there's at least one device that can be 
waken up to receive an attempt to call. And only then send a special 
push notification, containing a compressed session initiation iq, to 
simultaneously wake up a device, have the receiving app prepare for 
taking the call, presenting a user interface and waiting for the user to 
click 'accept call' or 'reject call', while in the meantime a connection 
to the XMPP server is being established.


Yes, potentially you could use information cached from previous times 
the recipient's clients were online, but in practice this is quite 
cumbersome.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Ralph Meijer]

On 17-02-2020 09:57, Dave Cridland wrote:
On Sun, 16 Feb 2020 at 12:49, Ralph Meijer <mailto:ral...@ik.nu>> wrote:


> Have you considered special disco nodes on the account that get
> synthesized by the server based on the disco information from
> registered devices?

I wondered about that. We could have a pair of disco nodes as well, yes.

> Do you think there's value in the ability to subscribe to this
> information via PEP?

I think there's severe disadvantages in having the information only 
available via PEP. But PEP remains our best choice for data that needs 
to be public and disseminated around a user's contacts.


The trouble is that PEP is also limited in the case of anything but a 
two-way presence subscription.


But using PEP for entity caps (XEP-0390-in-PEP, in effect) seems like a 
useful compromise, with the actual disco being held against the user's 
account.


My thinking here was that you'd have two nodes you can access both via 
disco as well as publish-subscribe. Notifications for the latter would 
be constructed by the server (as only publisher), and an entity could 
subscribe either directly (e.g. another server), or via +notify (other 
clients). One node for "all registered devices support these things", 
one for "at least on registered device supports these things".


A two-way presence subscription would not be needed if the nodes have an 
open access model. I haven't really considered in what cases having 
either an open access model, or not being able to use +notify, would be 
considered a downside.


I'm not sure about the need for CAPS hashes for this, next to the full 
disco#info in the payload of a pubsub item. If so, we probably should 
have two parallel nodes for subscribing (explicitly or implicitly) to 
just the hashes.


One thing I'm concerned about in general is what happens if I start 
sending presence to my contacts. I would get a PEP notification for each 
of my contacts with their capabilities. Bandwidth-wise having hashes 
here helps, but still it is a lot of traffic. Especially for mobile 
uses, it might be better to retrieve this information incrementally, 
through regular disco or perhaps a new IQ-get exchange for CAPS hash sets.


Crazy idea: a sibling element to the MAM result messages when doing an 
inbox request, with the CAPS hash set for the entry's other party.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Offline Feature Negotiation and Device Lists

[Ralph Meijer]

Hace you considered special disco nodes on the account that get synthesized by 
the server based on the disco information from registered devices? Do you think 
there's value in the ability to subscribe to this information via PEP?

--
ralphm

From: Dave Cridland 
Sent: Sunday, February 16, 2020 12:58
To: XMPP Standards
Subject: [Standards] Offline Feature Negotiation and Device Lists

> Hiya,
>
> We talked at the Summit about wanting to do device lists and things, but we 
> didn't actually get that far. That's fine, of course, we can't discuss 
> everything.
>
> But perhaps we can discuss what we want out of such a thing now.
>
> I'm thinking there's three potential "consumers" for such a feature-cluster:
>
> 1) Other Clients
>
> You have multiple devices, running potentially multiple clients. They may 
> wish to know about each other on a long-term basis.
>
> 2) Your Home Server
>
> Your Home Server might need to know about which clients you're actively using 
> in order to offer generalised services and things.
>
> 3) Other Entities
>
> Other entities may wish to know what features are, in general, supported 
> across all or some of your devices. They may only need to know aggregations 
> of this, or may need to know more details in some cases.
>
> I think - and may be wrong - that (1) and (2) are very closely related here. 
> They'd always be non-aggregated, and for things like authentication this 
> would be managed by the clients but executed upon by the server.
>
> (3) is different; I'm unconvinced that we ever want to allow a third party to 
> know the details of what clients exist (though ClientInitKeys will reveal 
> that to some degree). But we do want to indicate if, for example, "all" our 
> clients support encryption, or only "some". We might even want to indicate 
> meta-detail - all our clients may support encryption, but we might actually 
> prefer things not to be encrypted by default - but perhaps that's outside the 
> scope here.
>
> I think we build (1) and (2) out of a series of private PEP nodes, with one 
> item per client. We identify a client by UUIDv4 generated by the client. We 
> would have a PEP node containing XEP-0030 disco#info, which would then 
> synthesize the information for (3).
>
> I think we build (3) out of that information as two (or maybe more) PEP 
> nodes. A tricky challenge is that clients that don't understand (1)/(2) won't 
> be aggregated properly. I suggest, therefore, that use of clients that don't 
> support (1)/(2) causes some kind of fallback mechanism in (3) - perhaps we 
> assume it's an unknown client and move anything unsupported to "some".
>
> I think entity caps and end-to-end XEP-0030 will drastically reduce as a 
> result of this, by the way.
>
> Does all this sound like a starting point?
>
> Dave
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]

[Ralph Meijer]

On 02-01-2020 16:51, Sam Whited wrote:

On Thu, Jan 2, 2020, at 15:39, Dave Cridland wrote:

So I should accept your assertion that it is possible, but not
Philip's assertion on this list that it is not?


You should, because I have done so and shown that it was possible. At
the time you insisted that it didn't count because I had clearly copied
code from libsignal and it would therefore be encumbered in the same
way, and I pointed out that it was copied from NACL which is public
domain (libsignal also had clearly copied from here as all the comments
and much of the code was identical to NACLs).

I'm not sure why we keep having this discussion. It's been done.


Look, I haven't been following this as closely as some of you, I'm sure. 
However, from what I understand, there are a number of issues here:


 * There's no (public) specification of the actual protocol behind 
Signal (yet?).

 * libsignal cannot be used in non-GPL applications.
 * Re-implementations of the protocol cannot be said to implement the 
Signal Protocol and/or are considered derivative works of libsignal.
 * The protocol itself might receive changes and tracking libsignal is 
the only way to know.


So the problem is not whether or not the protocol could be, or has been, 
implemented independently through reverse engineering. Rather, what the 
XSF needs here, is a protocol specification that for the entire feature 
meets Objective 4 in XEP-0001.


The preference here is a document published by the Signal authors, maybe 
through the impending Signal Foundation. Then, XEP-384 can point to it 
and anyone can go and implement OMEMO without having to worry about the 
issues mentioned above.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]

[Ralph Meijer]

On 02-01-2020 14:36, Marvin W wrote:

[..]

The board did not update the diagram alone, it also specifically added a
rule in the text to allow that behavior [1]. If it happened before, it
was behavior outside the rules of XEP-0001.


We updated this for clarity, so there's a clear process.


The text says:

 A XEP of any type is in the Rejected state if the XMPP Council has
 deemed it unacceptable and has voted to not move it forward within
 the standards process.


You are merely quoting from the description of the Rejected state, it
does not describe when the council is allowed to do so. For a standards
track XEP there is a very accurate specification of the possible state
changes (even outside the diagram):


The ideal path is for a Standards Track XEP is to be advanced by the XMPP 
Council from Proposed to Draft to Final (the criteria for this advancement are 
described in the following paragraphs). However, an Experimental XEP shall be 
assigned a status of Deferred if it has not been updated in twelve (12) months 
(e.g., because of a lack of interest or because it depends on other 
specifications that have yet to move forward). In addition, rather than being 
advanced from Proposed to Draft, a Standards Track XEP may be voted to a status 
of Rejected if the XMPP Council deems it unacceptable. (Note that if a XEP is 
Deferred, the XMPP Extensions Editor may at some point re-assign it to 
Experimental status, and that, even if a XEP is Rejected, it is retained in 
source control and on the XMPP Standards Foundation website for future 
reference.) Finally, (only) a XEP author may voluntarily remove an Experimental 
XEP from further consideration, resulting in a status of Retracted.


Note how it explicitly says that *only* the XEP author may remove an
Experimental XEP from further consideration. You are trying to do so
without being the XEP author so you are clearly violating this rule.


The "removing from further consideration" means retraction in this 
context. That's is up to the author, but unrelated to moving to Rejected.



The bigger problem is the change by Daniel back in 2017, that changed 
the specification to be based on the so-called Signal Protocol. It is 
unclear to me if it is possible to implement OMEMO without libsignal 
and/or in non-GPL implementations. If that is indeed not possible, it 
violates one of the XSF Objectives set out in section 2 of XEP-0001:


  4. To guarantee that any person or entity can implement the protocols
 without encumbrance.

And thus, unless this restriction is somehow lifted, XEP-0384 cannot 
progress within our standards process. Eventually rejecting it seems a 
valid course of action to me, and I am not even sure if it can remain 
Experimental or Deferred because of this.


The earlier mentioned MLS effort at IETF specifies a new protocol based 
on the Double Ratchet Algorithm, which would be free to implement for 
everyone. Maybe we should put more effort in supporting this.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Ralph Meijer]

On December 21, 2019 12:32:03 PM GMT+01:00, Andrew Nenakhov 
 wrote:
>сб, 21 дек. 2019 г. в 16:21, Ralph Meijer :
>
>> Just making sure everyone has the same interpretation:
>>
>> Case 1) The text has the sequence ]]>. In this case, in XML the >
>MUST be
>> escaped (with , or equivalent character reference).
>> Case 2) All occurances of > not preceded by ]]. Here > MAY appear
>as-is,
>> or escaped. Both are valid.
>>
>
>Well. We diverge here, and read it differently. MUST be escaped clause
>uses
>AND, it's is not optiona. The reason it MUST be escaped is _for
>compatibility_, and we are in a compatibility game, aren't we?

If this were the case, there'd be no reason for having the 'may' earlier in the 
sentence. The compatibility clause refers to case 1 above. FWIW, it would be 
entirely possible to detect when you're in a CDATA section or not, but the 
authors chose to make it explicit that you must escape  > for this case. I am 
going to assume this is an artifact of XML's SGML ancestry and this rule is to 
make parsing easier.

So, having unescaped > is valid for case 2, and serializers may choose to do so.


-- 
Cheers,

ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Ralph Meijer]

On December 21, 2019 11:57:19 AM GMT+01:00, Andrew Nenakhov 
 wrote:
>сб, 21 дек. 2019 г. в 15:45, Philipp Hörist :
>
>>
>> I think you misunderstood the RFC, it's not a violation to send ">"
>> unescaped.
>>
>> > The right angle bracket (>) *may *be represented using the string "
>
>> ", and *MUST*, for compatibility
>> , be escaped using either "
>
>> " or a character reference *when *it appears in the string " ]]> " in
>> content, when that string is not marking the end of a CDATA section
>> .
>>
>>
>I have a different reading of this.
>
>MUST be escaped using
>EITHER 
>OR  character reference (WHEN it appears in the string ... ...)
>
>so OR branch is clearly used only for case listed in WHEN

Just making sure everyone has the same interpretation:

Case 1) The text has the sequence ]]>. In this case, in XML the > MUST be 
escaped (with , or equivalent character reference).
Case 2) All occurances of > not preceded by ]]. Here > MAY appear as-is, or 
escaped. Both are valid.

-- 
Cheers,

ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Ralph Meijer]

On December 21, 2019 10:57:02 AM GMT+01:00, Florian Schmaus  
wrote:
>On 18.12.19 16:00, Marvin W wrote:
>> It's indeed a good question if anything in XMPP allows servers or
>> in-between entities to do normalization. I was under the assumption
>that
>> servers do not change the codepoints. In XML [1] Characters with
>> multiple possible representations in ISO/IEC 10646 (e.g. characters
>with
>> both precomposed and base+diacritic forms) match only if they have
>the
>> same representation in both strings. Thus by XML specification,
>> normalization is changing the body.
>
>I am not sure if it is not a little bit far fetched to deduce from the
>XML "string match" definition that XMPP entities are not provided with
>a
>little bit of freedom to transform Unicode string representation within
>a certain degree. At least I am currently missing the link from the XML
>"string match" definition to "XMPP entities must use this when
>serializing/de-serializing XML".
>
>If we can make that link, then we do not need normalization. And we
>probably want to clearly state that requirement in rfc6120bis, because
>it is not obvious (at least for me).

I'd be quite sad if the character data would be normalized/canonicalized. Also 
I haven't seen this anywhere in XMPP implementations outside of JID matching.


>> Also the main reason why we shouldn't ask for Unicode normalization
>to
>> happen is that different Unicode version have different
>normalizations.> Thus if the sender normalizes with Unicode version X
>and calculates
>> offsets from that, then receiver normalizes with Unicode version Y
>and
>> determines the offsets there, they can end up in pointing to
>different
>> characters.
>
>We need Unicode agility anyway in XMPP, which I do not believe to be a
>big issue. Especially since Unicode is likely to introduce lesser
>changes with every future standard version.

Quite (except for JIDs). This is also a reason why for example Grapheme Cluster 
counting would bring us a world of pain.


-- 
Cheers,

ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Ralph Meijer]

On 20-12-2019 12:55, Andrew Nenakhov wrote:



чт, 19 дек. 2019 г. в 19:02, Ralph Meijer <mailto:ral...@ik.nu>>:


If you want consistent counting on all platforms and languages,
counting
Unicode characters seems to be the best way forward.


We do not dispute that 'counting unicode characters seems the best way 
forward'. However, we do dispute when to count them. It's more of a 
preference issue, but we chose to count characters in the XML doc we 
send, because XML standard is common for any platform and language.


Just to be clear. An XML Stream is encoded in UTF-8 and has additional 
processing (like entities) to represent a text. While does series of 
UTF-8 encoded characters are themselves also represent a sequence of 
Unicode characters (let's call them seq1), that sequence is not 
necessarily equivalent to the abstract sequence of characters that 
represents the above mentioned text (seq2).


Counting in seq1 and seq2 are different things as soon as there a CDATA 
sections, entities, etc, and I consider counting seq1 to be the wrong 
approach. I.e. I expect the character count for the text in the body 
element of the following equivalent XML snippets to be exactly 1 (the 
sequence containing the single character U+003c), and not 4, 5, 9, or 
13, irregardless of where you choose to count:


  
  
  
  

--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Ralph Meijer]

Oops, the following should have been sent to the list.

On 19-12-2019 15:02, Ralph Meijer wrote:



On 19-12-2019 13:59, Andrew Nenakhov wrote:
ср, 18 дек. 2019 г. в 20:12, Ralph Meijer <mailto:ral...@ik.nu>>:


    My assumption was that we are looking at character data on the
    abstract layer /after/ parsing XML. You shouldn't see entities there
    (they'd be resolved to their respective characters), nor should you
    see , and request the text for 
the `blah` node, I get an object that encodes the abstract sequence of 
characters: `less < more`. In Python, for example, that'd be 
represented by a unicode string object.


See also https://www.unicode.org/versions/Unicode12.1.0/ch03.pdf#G2212 
for various definitions around characters, code points, glyphs, 
graphemes, and the like. So yes, you'd be counting ZWJs and such for 
your example, and I think it tallies up to 7 for just man/man/boy/boy, 
without Fitzpatrick modifiers, hair variations, hair color, direction.


With regards to having to re-encode for HTML representation, as 
unfortunate that may be, other situations require other 
transformations, like encoded in UTF-8, for them to be used in other 
systems (UI, storage, etc.).


If you want consistent counting on all platforms and languages, 
counting Unicode characters seems to be the best way forward.



--
ralphm

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Ralph Meijer]

On 18-12-2019 16:40, Marvin W wrote:

[..]

Also that's a weird counting there, usually I would expect end to 
point to the position after the last referenced character - at least 
that's what you do in most programming languages (e.g. 
""[0:14] will give you "" without the 
last ";").


I'd not be opposed to changing the definition of 'end' here. Twitter 
Entities [1] also points to the character after.


[1] 
https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/entities-object


--
ralphm

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Ralph Meijer]

My assumption was that we are looking at character data on the abstract 
layer /after/ parsing XML. You shouldn't see entities there (they'd be 
resolved to their respective characters), nor should you see 

[Standards] Message Attaching, Fastening, References

[Ralph Meijer]

Hi,

With recent discussions on Message Attachments, Message Fastening, 
References, SIMS, edits (LMC, but any message) and Reactions, I took 
(quite) some time to write up a post [1] showing how they all could fit 
together. Lots of examples, and how they could be rendered.


I took the liberty to make some changes here and there (and use 
urn:example: namespaces where I did) based on previous discussions and 
suggestions. It is not at all meant to be the final word in this space.


Please discuss.

[1] 

--
ralphm

  
  Hi,

With recent discussions on Message Attachments, Message Fastening, References, SIMS, edits (LMC, but any message) and Reactions, I took (quite) some time to write up a post showing how they all could fit together. Lots of examples, and how they could be rendered.

I took the liberty to make some changes here and there (and use urn:example: namespaces where I did) based on previous discussions and suggestions. It is not at all meant to be the final word in this space.

Please discuss.

-- 
ralphm
  
https://ralphm.net/blog/2019/09/09/fastening"/>
  

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Ralph Meijer]

On 03/09/2019 15.02, Andrew Nenakhov wrote:



вт, 3 сент. 2019 г. в 17:14, Philipp Hancke >:


0353 was explicitly designed for push (by not including the full
payload
due to size constraints) in conjunction with 0357 and should not go to
MAM (hence no body).

This has some sad consequences like the lack of a message acting as a
call data record in the users history.


We're using Processing hints  element to make an archive store 
such messages. https://xmpp.org/extensions/xep-0313.html#hints


The way 0353 is supposed to work is:
1) you are offline but have a push-enabled client
(there is the more interesting scenario where some clients of yours are
online but none does jingle... and you would need to send a push
notification to your offline client that does... that is a generic
issue
however)
2) you get a push notification with the  element and know the
senders full jid, the session id and (FYI) the media types involved

3) your client requests that session at the sender. If that session
doesn't exist anymore the sender will respond with a message stanza
with
type=error and  (and potentially the jingle



No, I think push notifications do not work the way you describe. 
XEP-0357 says that a published  MAY contain additional 
custom information, however, all our implementations of Push 
notifications assume that NO additional information is relayed through 
third-party services (ejabberd, as I recall, doesn't even support 
publishing such additional information). Thus, we get NO  in 
push notifications, NO message text, nothing. Just notification to an 
app that it should wake up and update its data. Consequently, the only 
ways we can get this information are MAM and offline messages/ Since 
offline messages perform poorly when there are multiple user devices, it 
leaves us with just MAM.


I strongly oppose any suggestions to make push notifications work 
differently. If we start sending payload about calls via FCM/APNS, why 
stop at calls? We can just send full message text via push notifications 
as Telegram does. And at that point, why messing with XMPP at all? An 
FCM-only messenger can be coded in a week, it'll send and receive full 
message text via FCM, store messages on FCM cloud database and all will 
work admirably well.


Hi,

Let me start out saying that, like Philipp, my reading of the current
version of XEP-0353 is also that there is additional information shared
with the client over FCM/APNS. However, I must also say that neither
XEP-0353 nor XEP-357 make it clear how this should work exactly. This is
a problem, because it results in proprietary solutions for doing the
same thing. At minimum this should get another look and more concrete
examples with how existing push services would *actually* be used.

Andrew's description of their use of XEP-0353 introduces new elements in
the existing namespace, and adds a new iq-based exchange. Assuming this
is an experiment, I do want to point out that before it would go into
actual use, those would need to be moved to their own private namespace,
or be included in a next version of this specification (which might
require a new namespace).

With that all out of the way, let me describe what we did at VEON, as I
briefly alluded to in my presentation at the Summit [1]. Our approach
made calls server-mediated. I.e. the Jingle session-initiate was sent to
the callee's bare JID (their 'account'). The server then could send the
IQ on to online resources or via FCM/APNS. The latter notifications
actually did carry payload, including the media descriptions and
transport information (candidates).

The primary reason for doing it like this is speeding up the
negotiation. A receiving client can:

 * start evaluating the payload
 * configure the media library (in our case libwebrtc) to start media
streams on the device
 * re-establish the XMPP connection to the server
 * possibly request credentials for TURN
 * set up a TURN connection
 * retrieve vCards / avatars for the caller
 * etc.

In the mean while it can present the screen for allowing the user to
accept the call. As soon as the slow human user then presses 'accept'
you're immediately good to go and fully establish the call. This saves
several round-trips, and thus many centiseconds compared to XEP-0353 in
its current form, and even more if you have a model that relies on
re-establishing the XMPP connection before starting all of the above.

I want to note that our use cases where the XMPP connection might have
high latency but the actual media flows are local (even within office
networks).

Obviously, we also ran into the issue that notification payloads have
size limits. Thiago Camargo wrote a specialized compression library,
Shogun, to tackle this. It relies on a pre-shared dictionary for better
compression.

[1] 

--
Cheers,

[Standards] XMPP Summit 24: January 30/31 2020

[Ralph Meijer]

Hi,

Summer is almost over and the FOSDEM team has announced the dates of FOSDEM 
2020: Saturday 1 and Sunday 2 February. As usual the XSF will organise the 
anual European XMPP Summit ahead of FOSDEM. So put these dates in your calendar 
and start planning your visit:

* Thursday 30 January
* Friday 31 January

If you intend to visit, please sign up at https://wiki.xmpp.org/web/Summit_24 
as soon as you can, so we can gauge interest and plan accordingly. Most details 
still have to be figured out, and will be announced at a later time. Should you 
have ideas for agenda items or show-and-tells, do add them to the wiki.

If you have any questions or other suggestions, please send them to the Summit 
mailing list.

--
Cheers,

ralphm

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?

[Ralph Meijer]

On June 30, 2019 5:20:09 PM GMT+02:00, Sam Whited  wrote:
>On Sun, Jun 30, 2019, at 15:16, Ralph Meijer wrote:
>> Hmm. On which port? I want to point out explicitly that although 5223
>> has been used a bunch since before the IETF standardization, IANA has
>> assigned it to some HP management service. Hence my other proposal,
>> which is still currently unregistered.
>
>5222, assuming a client connection, probably. If we ever got a port
>registered for xmpps-client, I'd probably switch it to that. Although
>right now it seems fine to do both on 5222.

Do you know which server implementations currently support both TLS and non-TLS 
(with STARTLS) on the same port?


-- 
Cheers,

ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?

[Ralph Meijer]

On June 30, 2019 5:07:08 PM GMT+02:00, Sam Whited  wrote:
>On Sun, Jun 30, 2019, at 14:58, Ralph Meijer wrote:
>> Just to be clear, in the same way as for xmpp-client, as per RFC
>2782?
>
>I think so; I meant by fetching the A/ record of the domain part of
>the JID, and then attempting to perform direct TLS if a connection is
>established. Then again, if an attacker can poison my DNS to send me a
>"." SRV record, they can probably mess with the A/ records too so I
>suppose it doesn't matter all that much.
>
>Either way, if a connection is made at some point I'll probably try
>direct TLS whether it was advertised or not.

Hmm. On which port? I want to point out explicitly that although 5223 has been 
used a bunch since before the IETF standardization, IANA has assigned it to 
some HP management service. Hence my other proposal, which is still currently 
unregistered.


-- 
Cheers,

ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?

[Ralph Meijer]

On June 30, 2019 4:45:40 PM GMT+02:00, Sam Whited  wrote:
>On Sun, Jun 30, 2019, at 09:54, Dave Cridland wrote:
>> 1) It's not A/ fallback "as per RFC 6120", because we're talking
>>about a Direct TLS fallback. It should be per section... erm...
>> 2) This document doesn't mention a A/ fallback at all, and
>perhaps
>>that's right - do we ever want one with '368?
>> >  Please comment on-list.
>
>I've been meaning to change my library to do its fallback a little
>differently, including trying direct TLS fallback A/ fallback. DNS
>often doesn't use any sort of security measures, so to prevent DNS
>based
>downgrade attacks it seems best to me to always try direct TLS on the
>A/ record, just as we always try StartTLS even if it's not
>advertised.

Just to be clear, in the same way as for xmpp-client, as per RFC 2782?


-- 
Cheers,

ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?

[Ralph Meijer]

On June 30, 2019 11:53:39 AM GMT+02:00, Dave Cridland  wrote:
> [..]
>OK, two comments, which are essentially both my fault:
>
>1) It's not A/ fallback "as per RFC 6120", because we're talking
>about
>a Direct TLS fallback. It should be per section... erm...
>2) This document doesn't mention a A/ fallback at all, and perhaps
>that's right - do we ever want one with '368?

I think we should have a fallback, though. RFC 2782, in the section about 
"Usage rules", clearly specifies the resolution procedure, which includes a 
fallback using A/ records. E.g. in Twisted, SRV resolution is protocol 
agnostic, and behalves as in the RFC. Also, and more importantly, I think it is 
good for consistency.

I believe this also means that when we register the service name with IANA, we 
have to provide a port number. I suggest 5857, and leave the "why this one?" as 
an exercise to the reader.


-- 
Cheers,

ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?

[Ralph Meijer]

On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer"  
wrote:
>Hi list,
>
>It is not clear to me how to interpret, in a library connecting to an
>XMPP 
>service, a single SRV record for _xmpps-{client,server} which has `.`
>as the 
>target.
>
>For RFC 6120 _xmpp-{client,server} records (note the missing `s`), a
>`.` 
>indicates that the domain does not host an XMPP service at all, so
>attempting 
>to form a connection should stop right there (most notably, no fallback
>to 
>domainpart A/ lookup).
>
>How should this be interpreted for XEP-0368? Should a `.` indicate "I
>do not 
>speak direct TLS, but try _xmpp-client records"? Or should it indicate,
>right 
>away, that there is no XMPP service on the domain?

According to RFC 2782 it means the service xmpps-client is not available at 
this domain. So I think the answer should be the former. If there is a similar 
record for xmpp-client, though, you can't connect the regular way either. Maybe 
there's still another binding (BOSH, WebSocket) that could succeed, but
defining all possible permutations is a bit much.


>Whatever the consensus is, this should be written down in the XEP I
>think.

Agreed.


-- 
Cheers,

ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SIMS issues

[Ralph Meijer]

On 19/06/2019 19.46, Sergey Ilinykh wrote:

Hi

I mostly implemented SIMS in Psi and see next problems

1) The requirement for top-level reference element looks strange.
    In Most of the case when I want to share something, I don't want to 
refer to anything.
    If I really want to have a reference I would add it inside of 
.


The idea here is very similar to Twitter Entities [1,2]. The primary 
advantage of using References is that you can provide a fallback to 
refer to a location where the media can be found, in case the client 
doesn't support certain media descriptors. I don't think the current 
examples show this very well, but instead of the "view" being referenced 
in the example, you could have a URL to access the picture in a browser.


[1] 

[2] 



Also note that you don't have to use `start` and `end`, if you don't 
want to point to the plain text.



2) Top-level reference doesn't state what has to be in "uri" which is 
required


I agree that References still needs a lot of work. However, beyond the 
value needing to be a valid URI, I think everything works. How I used 
it, was providing a URI to retrieve the resource over HTTP. Do you have 
any particular concerns here?



3) Seems like only one  element is allowed while it's 
quite common to share multiple files at once with just one description. 
Sending each shared file via separate stanza doesn't look to be a good 
option since servers often limit sending rate and separate stanzas 
somehow corrupt logical scope.


But you *can* use multiple References. Would that work for you?


4) I want to use SIMS for voice messages but there is no any metadata 
for audio.
    I need at least duration and amplitude diagram there. Something like 
following would be really

    nice to have:
    
tune data here
   coding="u8">0,3,135,237,210,195,243,137,...,4,4,1

    


That sounds very interesting. I don't remember anyone suggesting a 
metadata format for this before and I didn't get to specify this in my 
previous project which would have eventually needed a format for voice 
messages. So what you could do is first define your own namespace and 
experiment with what works for your use case, and then eventually maybe 
submit it as a new XEP.


Also, I support this element would go inside the  wrapper?

--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Stanza Content Encryption

[Ralph Meijer]

Hi,


Dave, thanks for explaining why we have traditionally accepted specifications 
early. The IPR angle might not necessarily be compelling for some, but we have 
had issues around this before. Other organizations have similar policies, and 
IETF even has stronger ones, which include all discussion on lists.


So although authors or others might feel a proposal is not fully baked, we do 
prefer this. Having multiple (partially) competing specifications in 
Experimental stage is a good thing. Retracting after solid discussion is much 
easier.


Also note that the discussion on having a phase before experimental has come up 
before. Instead, we recently made some small adjustments to accommodate for 
this with the current stages. Adding another stage would just shift labels. I 
do agree that we should probably move a bunch of existing drafts forward.


--
ralphm

From: Dave Cridland 
Sent: Wednesday, May 15, 2019 18:15
To: XMPP Standards
Subject: Re: [Standards] Stanza Content Encryption

> Standard response:
>
> The process for XEPs in the XSF starts with the ProtoXEP submission - that 
> part is to decide if the XSF should take on the work.
>
> If the XSF does, it takes copyright of the XEP, and works on the contents.
>
> We do not have any IPR cover for something before this point, so I'm not 
> particularly motivated toward reading and commenting on unsubmitted XEPs, 
> sorry. Please do not try and change the process we have by adding a "pre 
> submission" stage to it - we really don't need an additional stage (and if 
> you think we do for some reason, we're probably doing something wrong to make 
> you think that way).
>
> More useful response:
>
> All I'd need to accept a full-stanza encryption XEP is:
> a) A way to know if the encrypted contents are a full stanza or just body.
> b) A way to know which elements in the encrypted contents override those in 
> the traditional payload.
> c) A way to know what encryption has been used.
>
> A challenge for (b) is that you don't always know what metadata elements 
> might be added by a server on the way through, and some metadata elements you 
> might include in the original (now encrypted) message may need to be both 
> duplicated on the outer wrapper and changed en-route.
>
> An example is security labels, which need to be translated through different 
> policies.
>
> As such, I'm not too worried if the (b) answer is quite a lot of hand-waving 
> for now.
>
> I think (a) and (c) are trivial, though. If your proposal covers those, just 
> submit it.
>
> On Wed, 15 May 2019 at 15:54, Paul Schaub  wrote:
>>
>> Thank you very much for your eager interest and numerous replies
>> *cough*, in other words, Thank you Florian for your reply :D
>>
>> I'm not quite sure, how exactly the process of negotiating expected
>> encrypted elements would look like. Do you think this may be done via or
>> similar to Entity Capabilities (XEP-0115)? I can see that this would
>> make it easier for adopters to gradually start implementing support for
>> one feature at a time (like start with support for  encryption
>> and then successively add support for other elements as well), but at
>> the same time I feel like this could enable "downgrade" attacks and
>> would diminish the "encrypt *all* the sensitive things"-approach that I
>> aim for.
>>
>> For now I'm trying to give useful sensible suggestions on what elements
>> are allowed inside the envelopes content element. If later we learn that
>> there are elements that are definitely not allowed at all, we might want
>> to come up with some sort of incomplete list of forbidden elements.
>>
>> An alternative approach that some people suggested would be to replace
>> the envelopes content element with a normal message stanza. That way
>> implementations could simply decrypt that stanza, check it for forbidden
>> elements and remove those and then feed the cleaned stanza back into the
>> XML stream. That way the client wouldn't have to reimplement listeners
>> for all the events. On the other hand, the client would probably want to
>> somehow mark the decrypted stanza as end-to-end encrypted.
>>
>> What do you think of this approach? Is it better, worse than the current
>> proposal? (reminder: http://geekplace.eu/xeps/xep-sce/xep-sce.html )
>>
>> I hope that there will be some more feedback from participants of this
>> list. I don't want to get the feedback only when the document lands in
>> the inbox folder ;).
>> If you think the idea behind the spec is a good idea - nice! If you
>> think it is a bad idea - even better! But please let me know why and
>> what you'd change.
>>
>> Happy Hacking!
>> Paul
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
___
Standards mailing 

Re: [Standards] MIX

[Ralph Meijer]

Hi,

I started working on this reply last week, I still need to fully address 
the PubSub/MAM/MIX thing, but that'll have to be a separate message. The 
rest is below.



On 12/03/2019 13.00, Dave Cridland wrote:

Hi all,

I've been writing a quick and dirty implementation of MIX.

>
> [..]
>
* Section 7.1.2 jumps through several hoops to ensure that joining a MIX 
Channel without subscribing to any nodes at all is a legitimate choice. 
I think the specification and implementation would be radically simpler 
if we didn't allow this - is there a use-case for this I'm missing? 
Without this, we can choose to have a "sensible default", or just make 
it an error.


In general, I think that explicit is usually better than implicit. While 
I can see how a sensible default might be useful. It brings up some 
issues with users that use multiple different clients.


Say that a server defaults to 'messages', 'presence', 'participants', 
and 'info'. Most desktop clients currently show presence in a side 
panel. Mobile clients, though, usually don't have/reserve screen 
real-estate for this, so wouldn't want to receive that. I'm going to 
guess that therefore, mobile clients might not subscribe to the 
'presence' node, when joining [fn 1], whereas desktop clients would. As 
node subscriptions are per user, not per resource, if you joined with 
that mobile client, you might not get presences in your desktop client. 
The desktop client might subscribe after the fact, when it finds out, 
but that's not ideal.


Of course a solution might be CAPS based notification filtering, but 
this requires your server to support MIX. This would also help the 
suggestion of a set of default subscriptions.


As for participants with no subscriptions, I think there is a valid use 
case for this: bots.


My suggestion is that we maybe wrap the  elements in an 
element that may be empty to denote no subscriptions, and absent to 
accept defaults.




* I'd dearly love to s/node/stream/ for the nodes within a channel.


And only refer to PubSub nodes being the thing that implement streams? 
Ok with me, but I wonder how that jives with the protocol, with `node` 
attributes in many places.



* Section 7.1.5 suggests MIX messages should be archived at the server. 
This is very different to MUC, where clients always request messages 
directly from the MUC. It's a useful model with non-chat and other 
non-trivial cases, where the archive might actually be synthesized on 
demand from the source of whatever history is. Is there a rationale 
here? The existing MUC/MAM model seems to work very well. I imagine this 
probably doesn't matter, beyond clients having to guess when they joined 
a channel in order to redirect MAM requests.


First of all, it should be more explicit that when we talk about the MAM 
archive of a channel, we mean the archive of the _messages stream_, not 
the other streams.


Indeed the upshot of having your own server record the history of 
messages from a channel, is that you get the combination of messages 
from all the streams you've been subscribed to. Also, it just comes in 
along with all of your other archived messages from contacts, instead of 
having to explicitly query all the archives of channels you are in.


To me, using MAM on the channel and other streams is useful for these cases:

 * Seeing what's in a channel without joining.
 * (Partially) back-filling a channel's history after you joined.
 * Maybe cover messages missed because of s2s outages?

That said, our implementation actually discarded stanzas of type 
'groupchat' from the user's archive, and indeed relied on the MIX MAM 
archive. :-(



* The XEP explains that a nickname is not needed, but also says it's 
needed for both presence and sending messages - or at least in Section 
7.1.4, it says it's not needed if you don't do either. Does this mean 
that a participant without a nickname cannot send messages or presence?


It is not clear to me why a nick would need to be required. In our own 
implementation, we only had non-anonymous rooms, used the user's phone 
addressbook to match JIDs, and filled in the blanks with vCard requests.



* Old participants never die, they're merely removed from the pubsub 
node and require endless searching through MAM, or having all their data 
copied to the outgoing messages. [..]


I don't understand what this is about. Can you expand?


* Nobody knows how MAM interacts with PubSub. I think it should store an 
archive of the stream of events emitted by the pubsub node: at least 
item publication events, and probably retractions. While this is all 
that's required to make MIX/MAM work well, I note that numerous other 
events also exist, which might be useful eventually.


I disagree, but will respond to this in a separate thread, as this is a 
big topic itself.



* Participants always have jids, even when anonymous. It's not wholly 
clear to me this is needed - the jids are the same computed ones used in 
presence 

Re: [Standards] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

[Ralph Meijer]

On 13/03/2019 15.09, Travis Burtrum wrote:

On 3/13/19 3:40 AM, Philipp Hörist wrote:

Whats the use case for this XEP?
Until now i only needed DNS querys to connect to the XMPP Server, i 
see this XEP is not helping with that as it already needs an active 
connection to the XMPP Server.


Like DoH, where you hard-code an IP, port, path, and whether to query 
via POST or GET to bootstrap your first DNS queries, the same can be 
done here by hard-coding a IP, port, JID, password, and resolver JID.


The syntax I use for this in jDnsProxy is this:

xmpp://208.68.163.210:5222#user=any...@example.org/resolver;pass=y0urPa55W0rDHere;resolverJid=d...@moparisthebest.com/listener


I haven't looked in-depth towards your proposal, but this is not
probably not a valid XMPP URI, or at least not how you think it is. As
per RFC 5122, the relevant ABNF productions look like this:

 xmppiri= "xmpp" ":" ihierxmpp
  [ "?" iquerycomp ]
  [ "#" ifragment ]
 ihierxmpp  = iauthpath / ipathxmpp
 iauthpath  = "//" iauthxmpp [ "/" ipathxmpp ]
 iauthxmpp  = inodeid "@" ihost
 ipathxmpp  = [ inodeid "@" ] ihost [ "/" iresid ]

In your case, I think your example would parses as:

iauthpath: 208.68.163.210:5222#user=any...@example.org
  inode: 208.68.163.210:5222#user=anyjid
  ihost: example.org
ipathxmpp: 
resolver;pass=y0urPa55W0rDHere;resolverJid=d...@moparisthebest.com/listener

  inode: resolver;pass=y0urPa55W0rDHere;resolverJid=dns
  ihost: moparisthebest.com
  iresid: listener

Although the # cannot be in inodeid (reserved and not in nodeallow), in
which case the alternative would consider everything behind the # to be
ifragment, but then ihierxmpp doesn't produce because there's no inodeid
+ "@" in the iauthxmpp, and there's no "/" + ipathxmpp following it.

You may want to have another look at this.

--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Ralph Meijer]

On 17/01/2019 14.29, Georg Lukas wrote:

[..]

I agree with the idea of crowd-sourcing the review of Deferred XEPs, and
to allow anyone to propose them for LC, with the LC resulting in either
of:

- Rejected or Obsolete (we have consensus that this is a dead end)
- Experimental with new author (if somebody volunteers to move it forward)
- stay in Deferred, because the exact status can not be determined.


Just to make it clear, (the first part of) the current process is as 
follows:



Before an Experimental XEP may be proposed to the Approving Body for 
advancement to Draft (Standards Track XEPs) or Active (Historical, 
Informational, and Procedural XEPs), the Approving Body must agree that the XEP 
is ready to be considered for advancement. Once the Approving Body so agrees, 
it shall instruct the XMPP Extensions Editor to (1) change the status of the 
XEP from Experimental to Proposed and (2) issue a Last Call for open discussion 
on the Standards list. [..]


This means that if the Approving Body does *not* agree the XEP is ready 
to be considered for advancement, it stays Experimental, without a Last 
Call. I think the same should hold for proposing advancement of Deferred 
XEPs to Draft.


Of course a negative decision here will come with reasons. If there is 
such interest, (new) authors can then pick up the XEP and have it move 
from Deferred to Experimental by editing the XEP to address those 
reasons for declining consideration.


The rest of the process after issuing Last Call then is the same as before.

XEP-0001 mentions that the XEP Author is expected to make changes during 
this process, but I think that if it is determined that the original 
author has abandoned it, the Approving Body could consider the person(s) 
that proposed advancement to take on that role.


I just issued a PR [1] with changes to XEP-0001 to address the above.

[1] https://github.com/xsf/xeps/pull/744

--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Ralph Meijer]

On 17/01/2019 12.43, Dave Cridland wrote:



On Thu, 17 Jan 2019 at 10:38, Ralph Meijer <mailto:ral...@ik.nu>> wrote:


Unfortunately, XEP-0001 seems to require an updated version for moving
it out of Deferred back to Experimental. I doesn't seem a reasonable
requirement to need changes to move (indirectly) to Proposed:


I think this isn't quite right.


XEP-0001 says that a document moves back to Experimental if a new 
version is published, but implies elsewhere that a document might move 
there for other reasons, somewhat at the whim of the Editor.


I would argue that there are several reasons why a document might move 
out of Deferred and back to Experimental.


Our process should always match reality - and if Deferred merely means 
"forgotten about", or "nobdoy cares", then any clear indication that the 
community does care should cause it to move out.


I agree that the Editor can still do this, which is why we asked for 
XEP-0345. But apparently we need to make it clearer/explicit in XEP-0001.


Also, if the document moves out of Deferred to Experimental, without a 
change, I think tools/deferrals.py requires changes to prevent to move 
it back to Deferred, if only by adding a new version block.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Ralph Meijer]

On 17/01/2019 11.25, Evgeny wrote:

On Thu, Jan 17, 2019 at 1:05 PM, Dave Cridland  wrote:
we do not require it until Final - not even Draft has an absolute 
requirement.


I thought transitioning to Draft requires Call For Implementors,
but whatever. Again this raises a question about how sane all
those XEP statuses nowadays. I know this is copied from IETF
workflow, but they have the same problems: a large number of RFCs
without implementations or with abandoned partial implementations.

But since the XSF standards development is severely understaffed
I think raising these questions makes even less sense (actually
this is true for almost any XSF workflow nowadays because of this).


I don't see large numbers of specifications being abandoned as a 
problem. It is a trove of thought experiments, some with code to go with 
it, that might be of use later. Leaving them as Deferred doesn't costs 
us anything.


I also want to note that the list of extensions [1] explicitly hides 
Deferred specifications by default to avoid distraction, based on 
similar earlier discussions.


[1] https://xmpp.org/extensions/

--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Ralph Meijer]

On 17/01/2019 10.19, Ненахов Андрей wrote:

I'd suggest not accepting XEPs without any kind of existing technical
implementation in the future. If one suggests a standard extension, he
should provide a working software that supports it.


This is explicitly not how our standards process has been set up. The 
idea here is that having a published document as a starting point makes 
it more likely that people are not entrenched in particular early design 
choices, and discussion on those happen within the greater community.


Please have a good read of the rationale of the current process as 
defined in XEP-0001.


Implementations for gaining more experience are encouraged, but not 
required. The only transition that requires (2) implementations is from 
Draft to Final.



> Also, XEP-0333 Chat Markers should not belong to deferred. It is
> widely used in XMPP clients.

I agree that this specification should probably be Proposed to move to 
Draft.


The project I've been working on has gained us some insight and I think 
that there are some things that could be explained better. E.g. the 
interaction with message archiving.


--
ralphm


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Ralph Meijer]

Replying to Dave and Goffi in one go:

On 17/01/2019 10.19, Goffi wrote:

Hello,

Le jeudi 17 janvier 2019, 09:55:17 CET Dave Cridland a écrit :

On Wed, 16 Jan 2019 at 20:48, Tedd Sterr  wrote:
Three things leap out at me:

1) Is it worth "cleaning Deferred"? That is, is having 177 documents in
Deferred state a problem?

2) If it is, our current solution to move them to some terminal, dead state
is to Last Call and then Reject them: (Deferred -> Experimental -> Proposed
-> Rejected). Is that OK? Does the community want 177 Last Calls of
pointless documents? Can the the Approving Body do this unilaterally (if, of 
course,
we allowed this in XEP-0001)?


I don't believe it makes sense to do that work for all Deferred 
specifications. It seems we can roughly divide all Deferred XEPs in a 
few categories:


1) More or less complete, considered of value, and maybe even has 
(multiple) implementations.


2) Considered of value, but needs more work to be accepted.

3) Interesting idea, but not pursued further.

Out of these, there are also cases where dependencies or dependents are 
still in flux (as Experimental), so that it doesn't necessarily make 
sense to advance them on their own (yet).


Especially XEPs of category 1 are candidates for moving to Draft. The 
biggest problem is that often the author seems to have abandoned the 
document before someone (the author or someone else) proposed the 
Approving Body (usually Council) to advance.


We should figure out if getting an Experimental XEP to Proposed requires 
the participation of the original author. I don't think this is needed.


Unfortunately, XEP-0001 seems to require an updated version for moving 
it out of Deferred back to Experimental. I doesn't seem a reasonable 
requirement to need changes to move (indirectly) to Proposed:


Given a spec that was last changed on January 18 2017, if someone had 
requested to advance to Draft yesterday, the Approving Body would have 
it in its queue for consideration and if deemed ready, it would issue a 
Last Call without changes. However, today, it would be Deferred, even 
though it might be just as ready as it was yesterday.


Therefore I think it should be possible to propose the Approving Body to 
advance a spec directly out of Deferred.


If the Approving Body doesn't deem it ready, the onus is on whoever 
would like to have it advance, to have changes made to meet the 
Approving Body's concerns. Such changes would make it take it out of 
Deferred, at which point it can be proposed again. This probably also 
solves the lack of an author.


If the Approving Body does deem it ready, the Editor should be able to 
do just that.


I want to note that last week the Editor was asked to move XEP-0345 
(Form of Membership Applications) to Proposed, even though it was 
Deferred, and issue a last call. This was requested by Board (which is 
also the Approving Body for this XEP), and has been honored.


Updating XEP-0001 to explicitly allow this route is probably a good idea.

I don't see the value of moving category 3 in any direction. These are 
usually not fully worked out, and having to move them to Rejected 
requires the Approving Body to make assumptions on what the full thing 
would look like. Just staying Deferred is just fine to me.




3) Finally, Tedd makes a very good point here in passing - the initial step
of skimming Deferred XEPs can be done by anyone in the community. While the
the Approving Body has to agree to put something into Last Call, anyone can 
request
that of the the Approving Body, as (in my guise as the Approving Body Chair) 
I'm happy to have
the the Approving Body vote on any Last Call as a general rule.


As mentioned above this seems to be what is meant by XEP-0001 as 
'deeming ready for advancement'. I strongly encourage people to let the 
respective Approving Bodies know which specifications they'd like to 
propose for advancement to Draft.




Note that some Deferred XEPs are actively used but either the authors are 
missing (that's more or less the case for XEP-0277 that Movim and SàT are using 
a lot), or the author wants time before moving (that's the case for 2 XEPs I've 
authored: XEP-0355 and XEP-0356: they are in a usable state, and I'm using 
them, but I plan to do changes on the long run and I feel it's too early to ask 
to move to draft).

In the first case, maybe there should be a way to change/extend the authors 
after some time (for instance edhelas or me could work on the XEP-0277).
For the later case, Deferred is a state that is OK for me, but I would not see 
the XEPs being killed (it's usable and used), I'm letting them in this state on 
purpose for the moment.


I believe in the absence of the original author, adding a new author 
that moves a XEP further along is just fine.


--
ralphm

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org

Re: [Standards] MIX: Getting hold of your own participant ID

[Ralph Meijer]

On 2018-12-07 10:27, Daniel Gultsch wrote:

[..] However it would be nice to also figure out by looking at the JID if that 
message might be a reflection or a message from ourself.


Isn't this case covered by the inclusion of the  as per 
example 30 (XEP-0369) and the prose just above it?



The messages sent to participants have a different message id to the originally submitted 
message. This does not impact most recipients, but it does not allow the message originator to 
correlate the message with the submitted message. To address this the MIX channel MUST include an 
additional  element in the  element of the message copy going 
back to the originator's bare JID. The  element holds the original id 
provided by the sender. This enables the originator to correlate the received message with the 
message submitted.


Besides correlating for the sender (the actual resource that sent it), 
it *also* allows your other resources to see that it was a message from 
your account. I assume this will also be stored as such in the user's 
own MAM archive.


For retrieval from the MAM archive of the channel itself, you'd still 
need to recognize your own Stable Participant ID, but that seems like a 
bit of an edge case.



I think it would be useful if on join the MIX channel could communicate our 
participant ID back to us and then PAM could put it in the roster as a child of 
the MIX annotation.


Example 18 (XEP-0369) shows that the join response includes the `id` 
attribute to hold the Stable Participant ID. A similar `id` attribute on 
the roster child should suffice:


  
  
  

--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] MIX channel info and xml:lang. Was: Re: MIX (XEP-0369) post-summit update to 0.8

[Ralph Meijer]

On 20/02/2017 04.32, Steve Kille wrote:

On 16 February 2017 19:51, Jonas Wielicki wrote:


I’m having trouble with § 3.9.7 and Example 4. The text says:


The name and description values MUST contain a "text" element and MAY
contain additional text elements. Where multiple text elements are

provided,

each MUST posses an xml:lang attribute that describes the natural

language

of the element. The format of the Information node follows Data Forms
(XEP-0004) [9].


I’m not sure how that would look like, and it would be nice to have an
example
of that. From my reading of XEP-0004, there is no such thing as multiple text
values (even with distinct xml:lang attributes) for text-single fields.

[Steve Kille]

I don't know how to do this! There has been a general desire to support 
mulitiple languages.   There were some examples around Subject, which don't 
apply directly here and they were dropped with Subject.

Can anyone provide details on how to encode it?


Was a solution for this ever discussed? This text is still there 
(XEP-0369, section 4.y), and I agree that XEP-0004 doesn't currently 
specify how to have multi-language values.


--
ralphm


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX: The Nick Name Problem (TM) aka The Identity Crisis (TM)

[Ralph Meijer]

On 29/11/2018 13.09, Daniel Gultsch wrote:

Hi,

[..]

So let me paint you a picture of my use case. In WhatsApp the user
creates an account; usually tied to a phone number - but that’s not
the point; and sets a Name and an Avatar. That name isn’t unique. It
would be pretty stupid if WhatsApp would prevent me from calling
myself 'Daniel' and would force me to call myself 'Daniel12345'. That
name and avatar is my identity on that chat system. When I’m in a
group chat with someone I’m still holding on to that identity. People
in that group chat expect to see that name and that avatar.

So when it comes to MUC my 'Identity Name' doesn’t map to MUC nick
names. MUC Nick names are unique. My identity name might not be. So
usually when I create WhatsApp-like group chats I set the nick to
something unique (most of the times the local part of my JID) and then
simply never display it but gather the 'true identity' by other means.
(Those other means can become pretty complicated and hacky)

So MIX in that regard is pretty close to MUC in that nick names are
unique for example. At least they are are somewhat optional. They are
not as much second class citizens as I would hope they would be - but
at least they are optional enough that I can ignore them.

But if I ignore them I have to discover the true identity of a JID
somehow. (That is display name (stored in a PEP node for example) and
avatar.


I'm working on something similar. In our case, we:

 * Have no explicit roster, but instead rely on phone address books.
 * Use vCards for retrieving names.
 * Have the local address book entry override vCard.
 * Don't have private channels.

So, instead of relying on MIX for nicks, we use the local address book 
entry (or vCard) based on the real JID of a participant.


We do the same for avatars.



In previous talks about MIX we have discussed creating 'avatar' and
other nodes on the mix channel. However even if we have those it would
basically mean that if I change something on my avatar or display name
I would then need to change them on every MIX channel I’m joined in.


Note that MIX has several ways of dealing with nicks. As mentioned in 
7.1.4 Setting a Nick:


  * The nick is registered with the user account in some way, for 
example as part of user provisioning with nick configured as an 
attribute in a directory service. For example, this could be chosen by 
corporate services that wish to ensure consistent nick values for a set 
of users and channels.
  * The nick is registered with the MIX service, as described in 
Registering a Nick .

  * The user explicitly sets the nick, as described in this section.
  * The MIX service generates the nick.

So instead of every room, you could potentially register the nick with 
the service, not every channel. Also, I don't think there's a 
requirement for them to be unique from a protocol point of view.


--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX (XEP-0369) channel discovery

[Ralph Meijer]

Hi Dave,

This seems to assume that all results from a disco#items request are 
uniform. This doesn't jive with my idea of how XMPP in general, and 
especially Service Discovery, should work. XEP-0030 clearly explains 
that after getting the items, you have to send a separate request to 
find out details for such items. From section 2:


  Discovering information about a child item MUST be accomplished by
  sending a separate discovery request to that item, not to the parent
  entity. (One result of this is that discovering complete information
  about an entire tree will require multiple request/response pairs in
  order to "walk the tree".)

I also note that there is a difference in how the items are returned for
MUC and MIX. For MUC, the items representing occupants have no node
attribute, whereas for MIX the items representing nodes naturally do
have a node attribute.

Section 4.2 (Items Nodes) also seems to imply that the node attribute
for Service Discovery is not meant as a filtering mechanism.

I am curious if just combining them would actually cause problems in
practice. Has this been tested?

--
ralphm


On 2018-09-25 22:32, Dave Cridland wrote:

Ralph,

As I vaguely recall, the problem wasn't disco#info clashing between MUC 
and MIX - as you say, those shouldn't clash.


The problem is disco#items, where MIX and MUC use disco#items to yield 
entirely different information. MUC will respond with room occupants, 
whereas MIX responds with channel nodes. It's the only clash between the 
protocols.


Seems fair to have the channel nodes be children of an abstract mix 
node. But this should only be needed for disco#items, not disco#info.


Dave.

On Thu, 20 Sep 2018 at 08:43, Ralph Meijer <mailto:ral...@ik.nu>> wrote:


Hi,

Recently I have been looking at discovery of entities to determine what
kind of thing it is, knowing nothing more than its JID. The starting
point is a client that shows a list of entities, based on past
conversations (MAM), ordered by last interaction. Entities could be
regular user accounts, bots, group chat rooms, etc.

The core idea behind XEP-0030 (Service Discovery) is that given a JID,
you can find out what kind of entity it is, by sending a Disco Info
request and getting one or more identities in return. Additional
information like supported features/protocols, and meta-data as Disco
Extension Data Forms (XEP-0128), can be included there, too.

Reading XEP-0369, section 6.3, on discovering channel information, I
see
that it currently requires the node attribute to be set to 'mix'. From
what I understand this is to allow a particular JID to support both MUC
and MIX, and have a way to request the MIX specific information.

The problem I have with this, is that it requires prior knowledge of a
certain JID (also) being a MIX channel. So you can't find out the
identity (the thing that's telling you what a JID is) without knowing
what the thing is. I do understand this works if you start out with
discovering the MIX service first, but I don't believe that should be
the only entry point.

I don't see the need for explicitly asking for the MIX information
(only). XEP-0030 and XEP-0128 support returning multiple identities as
well as multiple extension forms. So a Disco Info result, without node,
could look like this:



  
  
  
  
  http://jabber.org/protocol/muc%27/>>
  http://jabber.org/protocol/muc#stable_id%27/>>
  
  
  
  
  
  
  

  urn:xmpp:mix:core:0


  Witches Coven


  A location not far from the blasted heath where
 the three witches meet

  
  

  http://jabber.org/protocol/muc#roominfo


  The place for all good witches!

  



Note that I included the channel info from section 6.5 here. I was
surprised to find we aren't using XEP-0128 disco extensions instead of
doing a pubsub items request here. I /do/ see the value for having the
pubsub node as way to get notifications on changes, so having both
would
be even better. If you have to do a Disco Info request anyway, it saves
one request.

Finally, section 12, on Registrar Considerations, doesn't mention the
required registration [1] of the identity conference/mix. Unfortunately
one identity can have at most one extension form, so reusing
conference/text is probably not a good idea.

[1] https://xmpp.org/registrar/disco-categories.html#conference

-- 
ralphm

___
Standards mailing list
Info: https://mail.jabber

[Standards] MIX (XEP-0369) channel discovery

[Ralph Meijer]

Hi,

Recently I have been looking at discovery of entities to determine what 
kind of thing it is, knowing nothing more than its JID. The starting 
point is a client that shows a list of entities, based on past 
conversations (MAM), ordered by last interaction. Entities could be 
regular user accounts, bots, group chat rooms, etc.


The core idea behind XEP-0030 (Service Discovery) is that given a JID, 
you can find out what kind of entity it is, by sending a Disco Info 
request and getting one or more identities in return. Additional 
information like supported features/protocols, and meta-data as Disco 
Extension Data Forms (XEP-0128), can be included there, too.


Reading XEP-0369, section 6.3, on discovering channel information, I see 
that it currently requires the node attribute to be set to 'mix'. From 
what I understand this is to allow a particular JID to support both MUC 
and MIX, and have a way to request the MIX specific information.


The problem I have with this, is that it requires prior knowledge of a 
certain JID (also) being a MIX channel. So you can't find out the 
identity (the thing that's telling you what a JID is) without knowing 
what the thing is. I do understand this works if you start out with 
discovering the MIX service first, but I don't believe that should be 
the only entry point.


I don't see the need for explicitly asking for the MIX information 
(only). XEP-0030 and XEP-0128 support returning multiple identities as 
well as multiple extension forms. So a Disco Info result, without node, 
could look like this:



  













  
urn:xmpp:mix:core:0
  
  
Witches Coven
  
  
A location not far from the blasted heath where
   the three witches meet
  


  
http://jabber.org/protocol/muc#roominfo
  
  
The place for all good witches!
  

  


Note that I included the channel info from section 6.5 here. I was 
surprised to find we aren't using XEP-0128 disco extensions instead of 
doing a pubsub items request here. I /do/ see the value for having the 
pubsub node as way to get notifications on changes, so having both would 
be even better. If you have to do a Disco Info request anyway, it saves 
one request.


Finally, section 12, on Registrar Considerations, doesn't mention the 
required registration [1] of the identity conference/mix. Unfortunately 
one identity can have at most one extension form, so reusing 
conference/text is probably not a good idea.


[1] https://xmpp.org/registrar/disco-categories.html#conference

--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: "entity element" should be "subscription element"

[Ralph Meijer]

Hoi Melvin,


Thanks for your comment. I agree this is likely a leftover. If you want, you 
can create a pull request over at https://github.com/xsf/xeps. Otherwise, just 
attach a patch to an email here.


--
ralphm

From: Melvin Vermeeren 
Sent: Friday, July 27, 2018 18:09
To: standards@xmpp.org
Subject: [Standards] XEP-0060: "entity element" should be "subscription element"

> Hi, 
>
> I noticed something minor when working on PubSub which initially caused some 
> confusion. Section 6.1.6 of XEP-0060: Publish-Subscribe says: 
> > therefore the SubID MUST be unique for each node+JID combination and the 
> > SubID MUST be present on the entity element any time it is sent to the 
> > subscriber 
>
> I believe "entity element" should be "subscription element" here. A search on 
> "entity element" gives a few more hits, It appears they should all be 
> replaced 
> as well since "" appears to not exist anymore currently. 
>
> Looks like they are leftovers from an old version of the XEP, since 1.8's 
> changelog has the following item: 
> > Changed  element to  element in response to 
> > subscription request 
>
> I am not yet familiar with sending patches for XEPs. Could someone either 
> make 
> the change or give me some directions? Thanks. 
>
> -- 
> Regards, 
>
> Melvin Vermeeren
> ___ 
> Standards mailing list 
> Info: https://mail.jabber.org/mailman/listinfo/standards 
> Unsubscribe: standards-unsubscr...@xmpp.org 
> ___ 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0369: MIX - About create a room/channel

[Ralph Meijer]

On 2018-04-24 09:09, Steve Kille wrote:




-Original Message-
From: Standards <standards-boun...@xmpp.org> On Behalf Of Ralph Meijer
Sent: 23 April 2018 21:41


So, does that mean you can create a room in such a way that you lack full
control over? That doesn't sound optimal, although I like explicit over

implicit.
[Steve Kille]

I agree that explicit is good.   It is also clean if you want to create a
room without an owner or with owners not yourself.



What happens if you omit the Owners field? Is the default a single item,

being

the bare JID of the creator?

[Steve Kille]

3.9.11 says:  " Bare JIDs with Owner rights as defined in ACL node. When a
channel is created, the JID creating the channel is configured as an owner,
unless this attribute is explicitly configured to another value."

This is effectively saying Owner is mandatory.   I think that I will add
text to explicitly say that a channel must have an owner.

Does this make sense?


Section 3.9.1 says two things:

  1) Only owners are allowed to modify the channel configuration node.

  2) There MUST always be at least one Owner for a Channel. Owners,
  Administrators, Participants, and Allowed are optional and do not need
  to be set. Where no owner is explicitly set, it is anticipated that a
  server administrator will have owner rights. [..]

I think 1 follows from 2, simply because if you have no owner, there
can be no changes to the Channel afterwards. So I do think that 2) makes
sense. I'm a bit unsure about the part where it anticipates about server
administrators, and how that interacts with the MUST in the previous
sentence. If you value explicit over implicit, I'd do away with
this bit of vagueness.

The text for 2 continues with:

  “Rights are defined in a strictly hierarchical manner following the
  order of this table, so that for example Owners will always have
  rights that Administrators have.”

This seems to imply that Administrators and Owners "have the rights of"
Participants. Are they actually in the list of Participants? If so:

 - What does it mean to be in the list of Participants (including
   Administrators and Owners), if there was no explicit join from that
   bare JID?

 - Is such an entity just not subscribed to any nodes?

 - How do roster modifications work in this case?

 - Can an administrator modify this list with a PubSub publish, like the
   Allowed node? The above would also imply that you can add people to a
   channel without using the invite system in 6.1.16.

 - Does leaving the room affect these lists?

 - If so, what happens when the last Owner leaves the room?

--
ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0369: MIX - About create a room/channel

[Ralph Meijer]

On April 23, 2018 5:34:06 PM GMT+02:00, Steve Kille  
wrote:
>
>
>> -Original Message-
>> From: Manuel Rubio 
>> Sent: 23 April 2018 16:12
>> To: XMPP Standards 
>> Cc: Steve Kille 
>> Subject: Re: [Standards] XEP-0369: MIX - About create a room/channel
>> 
>> Hi Steve,
>> 
>> thanks for your answers. About one I think was omitted, if I (hag66)
>create a
>> channel saying the owners are "hecate" and "greymalkin", am I an
>owner for
>> that channel?
>
>[Steve Kille] 
>
>The intention is that you state this explicitly.   You can choose to
>create a room and assign others as owners.   I'll add a few words

So, does that mean you can create a room in such a way that you lack full 
control over? That doesn't sound optimal, although I like explicit over 
implicit.

What happens if you omit the Owners field? Is the default a single item, being 
the bare JID of the creator?


-- 
Cheers,

ralphm
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] RFC 6120 vs. Bind2 XEP

[Ralph Meijer]

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 6120, section 7.1. says that clients must
do resource binding, section 7.2. declares support for it mandatory in
the client, and in section 7.4. it is definitely stated that (hilight by
me)


[...] the server MUST include a 
element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace
in the stream features it presents to the client.
[...]
Upon being informed that resource binding is mandatory-to-negotiate,
the client MUST bind a resource to the stream as described in the
following sections.


This, in my opinion, means that RFC 6120 has to be officially amended to
support Bind2 as in case of conflicts between a XEP and the RFC, the RFC
must take precedence.

Apart from the formal argument, disregarding RFC 6120 and revising core
XMPP functionality via a XEP means that a good part of RFC 6120 (namely
section 7) does not reflect the reality anymore when Bind2 is
accepted. Someone creating a new XMPP client naturally starts by
implementing RFC 6120, only to discover that it is obsoleted by
practice. I do think that such severe revisions deserve a note in the
RFC.


This is simply not true. Nobody is disregarding RFC 6120. Traditional 
resource binding remains mandatory to implement and any new XMPP client 
can do everything described in RFC 6120/6121 as normal. Bind2 just 
provides an alternative with attractive additional properties, like 
faster resumption.


We are in the process of defining Bind2 and figuring out if it can 
replace the traditional resource binding eventually. If and when we do 
think this is the case, then yes, we should go and do another round of 
revised specifications at the IETF. This has already been mentioned as 
the future process.


--
ralphm

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] RFC 6120 vs. XEP

[Ralph Meijer]

On 07-02-17 13:41, Marvin Gülker wrote:

Hi,

On Mon, Feb 06, 2017 at 04:46:58PM -0700, Peter Saint-Andre wrote:

RFC 6120 author here. :-)


Great! :-)


Note that the order of features matters. In the Bind2 proposal, the order is
this:


I have to disagree. RFC 6120, section 4.3.2 says this, though it is
marked as an Implementation Note:


Implementation Note: The order of child elements contained in any
given  element is not significant.


Thus, I'm not really sure whether I agree with your understanding of RFC
6120's text.


I don't see why this is a debate at all. The order isn't even relevant. 
A client that understands Bind2 can simply see the feature appearing 
next to the RFC 6120 one, and choose to negotiate it instead of that.


A protocol is an agreement on how to do things. The agreement here is to 
bind a resource *instead of the original way*. If the server advertises 
it and the client uses it, you're done.


--
ralphm

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] FOSDEM 2017 RTC Devroom and XMPP Summit

[Ralph Meijer]

Hi all,

Daniel Pocock has once again been taken on the job of managing the 
submissions for the Real-Time Communications developer room at FOSDEM. 
I'm sure you've seen his reminders for the CfP [1]. He mentioned that 
there a quite a number of submissions, but not so many on XMPP 
specifically, yet.


Even though the official deadline has already passed, please do submit a 
proposal as soon as possible, if you'd still like to present in that 
devroom. The schedule will probably be made next week.


This is also a good time for a reminder to sign up for the XMPP Summit 
on our wiki [2]. The sooner people sign up, the easier it is to look at 
venues and possibly hotel discounts. Please take the 3 minutes it takes 
to add your name there.


Hope to see you all in Brussels again!

--
Cheers,

ralphm

[1] 
[2] 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SASL's DIGEST-MD5: host or domain?

[Ralph Meijer]

On August 16, 2016 4:51:51 PM GMT+02:00, Christian Schudt 
 wrote:
>Hi,
>
> 
>
>when using Java's SASL API [1], you would use the following to create a
>SASL client for DIGEST-MD5 authentication:
>
> 
>
>Sasl.createSaslClient("DIGEST-MD5", authzid, "xmpp", serverName, null,
>cbh);
>
> 
>
>The fourth parameter "serverName" will be used in the digest-uri
>
>It's documented as [1]:
>
>serverName - The non-null fully-qualified host name of the server to
>authenticate to.
>
> 
>
>So I think it correctly sticks to the specification (host is correct,
>domain is wrong).
>
> 
>
>That said, I did it wrong, too in my implementation, but will fix it
>(i.e. use hostname instead of domain), so that I comply with the API
>contract, too. Thanks for pointing it out.
>
> 
>
>-- Christian
>
> 
>
>[1]:
>https://docs.oracle.com/javase/8/docs/technotes/guides/security/sasl/sasl-refguide.html
>
>[2]:
>https://docs.oracle.com/javase/7/docs/api/javax/security/sasl/Sasl.html#createSaslClient(java.lang.String[],%20java.lang.String,%20java.lang.String,%20java.lang.String,%20java.util.Map,%20javax.security.auth.callback.CallbackHandler)
>
> 
>
>Gesendet: Dienstag, 16. August 2016 um 14:41 Uhr
>Von: "Guus der Kinderen" 
>An: "XMPP Standards" 
>Betreff: [Standards] SASL's DIGEST-MD5: host or domain?
>
>Hi,
>
>Over the last few days, some of us at IgniteRealtime have been having
>fun with the DIGEST-MD5 SASL Mechanism - specifically, with it's
>digest-uri value. The syntax of this value is:
>  
>
>serv-type "/" host [ "/" serv-name ]
>
>
>It's generally accepted [1] that the applicable value for the serv-type
>part is "xmpp". So far, we've not used the optional "serv-name" part.
>The "host" part is a cause of confusion though.
>
>We found that, when handling the server side of things, Openfire
>expects the "host" part of the digest-uri value to be an XMPP domain
>name. This conflicts with the specification in RFC2831, which defines
>the "host" part as follows:
>  
>
>"The DNS host name or IP address for the service requested.  The DNS
>host name must be the fully-qualified canonical name of the host. The
>DNS host name is the preferred form; see notes on server processing of
>the digest-uri."
>
> 
>
>Clearly, this defines a host name to be used, not the service domain
>name. This is further confirmed on "our" wiki [3] where "host" is
>defined as: 
>
>
>"The DNS hostname or IP address for the service requested (though the
>DNS hostname is preferred). For XMPP, this should be set to the
>hostname of the remote server."
>
> 
>
>All of the above let me to experiment with changing our implementation:
>instead of expecting the client to send the domain name, let's have a
>fully qualified host name [4].
>
>Interoperability problems galore!  
>
> 
>
>The change above, although "correct" in the terms of following the RFC,
>appears to clash with existing XMPP client implementations. So far,
>we've found that Smack, Conversations, and Gajim will use the XMPP
>domain name, instead of the fully qualified host name when constructing
>the digest-uri value. They were the first three implementations that we
>checked. With the three out of three score, I'm assuming that most
>other implementations will behave the same. (How does your
>implementation do this?)
>
> 
>
>How, as a community, should we tackle this, if at all? On one hand: if
>indeed everyone is doing the same thing now, it would probably hurt
>interoperability when "fixes" are applied. Then again, there's bound to
>be some implementations that actually follow the specifications, and
>now fail to authenticate.
>
> 
>
>For Openfire (and perhaps all server implementations), I'd love to work
>towards a solution in which the DIGEST-MD5 mechanism implementation
>will accept both the domain name as well as the fully qualified host
>name. That will allow both variants to connect successfully, but has
>practical issues [5].
>
> 
>
>Regards,
>
> 
>
>  Guus
>
>Now that Dave has come
>aroundhttps://tools.ietf.org/html/rfc2831http://wiki.xmpp.org/web/SASLandDIGEST-MD5This
>change was needed to resolve another, unrelated issue, which is why we
>started looking into this in the first placeWe either have to implement
>our own implementation (daunting task), or find a suitably licensed
>third party implementation (haven't found one yet) 
>
>___ Standards mailing list
>Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe:
>standards-unsubscr...@xmpp.org
>___
>
>
>
>
>
>___
>Standards mailing list
>Info: http://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

I think that it is unwise for clients to start "fixing" this, to be honest. 

Re: [Standards] SASL's DIGEST-MD5: host or domain?

[Ralph Meijer]

On August 16, 2016 3:09:31 PM GMT+02:00, Kurt Zeilenga 
 wrote:
>
>> On Aug 16, 2016, at 5:41 AM, Guus der Kinderen
> wrote:
>> 
>> Interoperability problems galore!
>
>Welcome to DIGEST-MD5!
>
>I recommend avoiding this mechanism.  Use SCRAM instead (preferably
>PLUS channel bindings) instead.
>
>-- Kurt
>
>
>
>___
>Standards mailing list
>Info: http://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

Well sure. It's been deprecated by the XMPP community, too. However it is still 
abundant in the wild.

It seems to me that we just have to live with the form xmpp/example.org, where 
the host part really is the domain instead of the hostname. Of course, 
accepting the more correct version of xmpp/foo.example.org/example.org is 
commendable, but not required.

FWIW, the XMPP SASL code in Twisted also does the 'wrong' thing.


-- 
ralphm___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0375: View from Openfire

[Ralph Meijer]

On 2016-07-12 05:11, Sam Whited wrote:
> I've tried to address some of this feedback here:
> 
> https://github.com/xsf/xeps/pull/206
> 
> I think the only thing I left out was getting rid of the IM compliance
> suites (in case any of the IoT crowd chime in).
> 
> I also added MIX as a possible provider of "Group Chat" and merged the
> web compliance suites into a single item, making BOSH and Websockets
> interchangeable. More suggestions for web-friendly features would be
> appreciated from web client authors (maybe they're similar to mobile
> concerns?).
> 
> Let me know what you think. It could probably use a bit of description
> about what the providers column means now; I envision a comma as being
> an OR as in "MUC or MIX".

Although I strongly believe in the prospects of what MIX will bring to
the table, to me, it doesn't make sense to put in any reference to MIX
at this point in time. The point of this suite is to get
interoperability between a wide array of client and server
implementations so that things Just Work™. MIX is nowhere near mature
enough that this is achievable within 2016.

-- 
ralphm
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX progress

[Ralph Meijer]

On 2016-07-05 12:23, Kevin Smith wrote:
> On 5 Jul 2016, at 11:21, Florian Schmaus  wrote:
>>
>> On 05.07.2016 12:07, Kevin Smith wrote:
>>> On 5 Jul 2016, at 11:06, Florian Schmaus  wrote:

 On 05.07.2016 11:10, Kevin Smith wrote:
> On 5 Jul 2016, at 09:51, Florian Schmaus  wrote:
>> XEP development behind closed doors is not desirable.
>
> To be fair, that isn’t what’s happening here, it’s just that Steve wants 
> to double-check that the text reflects the Summit agreements before he 
> submits.

 How would one get involved in MIX development (besides participating in
 the summit)?
>>>
>>> Discussing the decisions made at the summit, or making further suggestions, 
>>> presumably.
>>
>> Where can I find those decisions?
> 
> They were sent to the list.

To be exact, Steve wrote two sets of notes on the discussion at the XMPP
Summit in Brussels. They were sent to the Summit list, instead of here,
which might be considered unfortunate in retrospect. In any case, you
can find them here:

  http://mail.jabber.org/pipermail/summit/2016-January/001794.html
  http://mail.jabber.org/pipermail/summit/2016-January/001795.html

-- 
ralphm
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A MIX Tape of suggestions.

[Ralph Meijer]

On 23-05-16 13:28, Dave Cridland wrote:

2) Creation

There's no way to create a room. Given the complexities of room locking
in '45, I'd like to have an explicit create, and I have a reasonably
strong preference (not absolute) to having this directed to the service
rather than a non-existent channel. ("Channel Create Thyself" does not
appeal).


I like the guideline “explicit is better than implicit” [1], so fully 
agreed here.



What about:


   
 
   


I'd like the channel attribute to be optional, and the result to be a
create element with all the optional bits filled in. (ie, include the
channel name and form).

The channel address being optional allows for a straightforward use-case
for creating an ad-hoc multiparty conversation; an absent configuration
form should be treated by the service as "make up some settings suited
to an ad-hoc multiparty conversation".


I assume that the server will send back the address of ad-hoc rooms in 
the response to this request (much like pubsub node creation), right?


Also, I wonder if the attribute should indeed have the whole JID here, 
or just the localpart. Also, can a server change the localpart before 
creating the room?


--
ralphm
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A new SASL Profile strawman

[Ralph Meijer]

On 04-05-16 20:45, Lance Stout wrote:



On May 4, 2016, at 7:00 AM, Dave Cridland <d...@cridland.net> wrote:

Folks,

I had a nice chat with Ralph Meijer, and we idly discussed replacing the SASL 
profile in order to gain access to 2FA, fold in the Stream Resumption (Florian 
Schmaus's design, in effect), and make it a little more extensible, 
particularly with more detailed error messaging.



The basic proposal here looks sensible to me, and support for 2FA would be 
awesome. However, it does carry the cost of needing to upgrade one of the 
fundamental parts of XMPP session negotiation.

To be honest, if any such price is to be paid, I want it to bring significant 
benefits that can simplify the startup process.


While Dave proposes an entirely new namespace for this, I believe that
all of the new features could be done by extending the current
functionality:

 * The new attributes could be used as-is on the current  and
elements.

 * Instead of having , you'd have to use  more
   creatively:

* Introduce a new defined condition  (or somesuch).

* Allow for meta-data of this condition, to hold the
  optional success data and mechanisms for the next step, either
  as child-elements or as an application-specific condition element.

* If we would start allowing application-specific error conditions,
  we could use  as the main condition.
  Unfortunately that is currently defined to only be in response to
  an  request, and not after .

* After this 'failure', the next step would simply be a new round
  starting with .


The down-side of this might be that we need to do this work at the IETF.

Dave and I also discussed doing (just) 2FA from within new SASL
mechanisms, but for me that has some downsides:

 * Harder to reuse existing implementations of mechanisms, as you need
   to somehow wrap the exchanges.

 * Often, a server will determine the need for another factor only
   *after* completing the first one, based on the verified identity. So
   a server cannot advertise such wrapping mechanism, nor can the client
   choose this if presented with it.

In practice, uou are quickly building a protocol within a mechanism.



The proposal is already tying itself to stream management, so let's push that 
further:

1. Opting to use new-SASL is also enabling stream management. This seems to be 
implied already for the proposal to meet its goals, but it would need to be 
more explicit.


Yeah, this might be a bit weird. I wonder if, instead, we could do the
stream management exchange around SASL like so:

  C: 

  C: 
  [..]
  S: 

  C: 
  S: 
  S: 
  S: 

Maybe with some indicator that the client knows that it has to complete
SASL before resumption is acknowledged. I am thinking of an attribute on
 to that effect. This way, it could all still be a single round
trip.



2. JID binding included in new-SASL success response, so no need to manually 
request a binding (maybe even go so far as to not allow requesting a resource, 
just be assigned one)


Even though people have suggested that client-chosen resource is a bad
idea, I haven't seen compelling argument for it yet. A stable identifier
for specific client instances still seems like a valid use-case to me.
Also note that this is a all Core, so isn't specific to IM-type
applications.

If you are saying that one shouldn't need / be able to bind a resource
when resuming a session, I fully agree. I expect switching resources for
a resumed session yields all kinds of weird issues.



Yes, this combines several existing, but related, stream features. This 
combination of features is one of the most well-trod of cow paths, and is what 
inflates the number of round-trip requests needed to start a usable session.


Agreed.

--
Cheers,

ralphm
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Pubsub Account Management (PAM)

[Ralph Meijer]

Hi,

What is the status of the PAM proposal [1]? I found that it was approved 
as experimental XEP by the Council on February 3, but I don't see it 
published. Has this slipped through the cracks?


[1] 

--
Cheers,

ralphm
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Who's coming to FOSDEM / XMPP Summit 19?

[Ralph Meijer]

Hi all,

Looking at the list of participants at for the upcoming Brusses summit 
at , 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 . 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  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.
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Fwd: [jdev] [CFP] FOSDEM 2016, RTC devroom, speakers, volunteers neeeded

[Ralph Meijer]

ist in this
- organizing one or more restaurant bookings (dependending upon number of
  participants) for the evening of Saturday, 30 January
- participation in the Real-Time lounge
- helping attract sponsorship funds for the dev-room to pay for the
  Saturday night dinner and any other expenses
- circulating this Call for Participation to other mailing lists

FOSDEM is made possible by volunteers and if you have time to contribute,
please feel free to get involved through https://volunteers.fosdem.org/

Related events - XMPP and RTC summits
=

The XMPP Standards Foundation (XSF) has traditionally held a summit
in the days before FOSDEM.  There is discussion about a similar
summit taking place on 28 and 29 January 2016
http://wiki.xmpp.org/web/Summit_19 - please join the mailing
list for details: http://mail.jabber.org/mailman/listinfo/summit

We are also considering a more general RTC or telephony summit,
potentially on 29 January.  Please join the Free-RTC mailing list
and send an email if you would be interested in participating,
sponsoring or hosting such an event.

Social events and dinners
=

The traditional FOSDEM beer night occurs on Friday, 29 January

On Saturday night, there are usually dinners associated with
each of the dev-rooms.  Most restaurants in Brussels are not so
large so these dinners have space constraints.  Please subscribe
to the Free-RTC mailing list for further details about the
Saturday night dinner options and how you can register for a seat:
https://lists.fsfe.org/mailman/listinfo/free-rtc

Spread the word and discuss
===

If you know of any mailing lists where this CfP would be relevant, please
forward this email. If this dev-room excites you, please blog or microblog
about it, especially if you are submitting a talk.

If you regularly blog about RTC topics, please send details about your
blog to the planet site administrators:

  http://planet.jabber.orgral...@ik.nu

  http://planet.sip5060.net   dan...@pocock.pro

  http://planet.opentelecoms.org  dan...@pocock.pro

Please also link to the Planet sites from your own blog or web site.

Contact
===

For discussion and queries, please join the free-rtc mailing list:
https://lists.fsfe.org/mailman/listinfo/free-rtc

The dev-room administration team:

  Daniel Pocock <dan...@pocock.pro>
  Ralph Meijer <ral...@ik.nu>
  Saúl Ibarra Corretgé <s...@ag-projects.com>
  Iain R. Learmonth <i...@debian.org>

___
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___
--- End Message ---

Re: [Standards] Deprecating IBR

[Ralph Meijer]

On 2015-11-16 15:55, Matthew Wild wrote:
> I understand that open registration is a
> problem on the federated network, but it's not a protocol issue and
> XEP-0077 as a protocol should not be deprecated.

Agreed. It is mostly about what happens after registration, too. In the
end, for spammers it is all about cost: if creating an account *and
then* sending out stuff to random people is cheap, then you have a
problem. I.e. if you you remove IBR, but then have a sign-up form on a
website that's equally cheap to get an account from, you haven't solved
anything.

-- 
ralphm

Re: [Standards] Deprecating Privacy Lists

[Ralph Meijer]

On 2015-10-12 21:20, Evgeny Khramtsov wrote:
> Mon, 12 Oct 2015 16:04:43 -0300
> Ben Langfeld  wrote:
> 
>> "We want to deprecate Privacy Lists because we think it's a bad spec."
>> "You'll have to write a good spec first!"
>> "A good spec would be nice. Do you (or anyone else in the community)
>> fancy helping write one?"
>> "No! You (XSF council / mystical XEP-writing fairies) have to do it.
>> Don't you dare deprecate Privacy Lists!"
>> "Yeah, developers shouldn't have to write specs. That's the project
>> manager's job. Developers just translate specs into code."
> 
> Well basically that's true. Not in the details because you added to
> many emotions here (probably you're a very hurting person), but true.
> Ah, and still no technical arguments except "Privacy Lists are complex
> (just like PubSub)" :)

No. Some arguments, gotten from implementation experience, are actually
listed in the Blocking Command (XEP-0191) introduction:

RFC 3921 [1] includes an XMPP protocol extension for communications
blocking, which has since been moved to Privacy Lists (XEP-0016)
[2]. Unfortunately, because the privacy lists extension is quite
complex, it has not been widely implemented in servers and has been
implemented virtually not at all in clients. This is problematic,
since the ability to block communications with selected users is an
important feature for an instant messaging system (and is required
by RFC 2779 [3]). However, the full power of privacy lists is not
needed in order to block communications, so this document proposes a
simpler blocking protocol that meets the requirement specified in
RFC 2779 and can be implemented more easily in XMPP clients and
servers.

This has been recognised since 2006 and resulted in the deprecation of
the same protocol as being part of the XMPP IM specification over at the
IETF. Granted, probably more implementations of Privacy Lists happened
since then, but I have yet to meet a person that enjoyed working on
that.

One of the major problems on the server side, is that processing all
those, possibly complex, lists of rules, is very resource intensive.
This hurts performance and is why people are now actively moving away
from it. E.g. Prosody deciding is will not consider it part of its core,
with maintenance of the module passed to whomever wants to still spend
time on it.

One of the major problems on the client side, is that implementing a
proper user interface for this protocol is a challenge and unlikely to
be very intuitive. Have a look at Gajim's implementation. It seems to do
everything the protocol specifies, but it is very confusing. See also
. Suggested solutions in that ticket
include breaking it down into simpler dialogs for specific use cases and
then create/modify privacy lists rules for the result. This is a
problem, because not only does the client developer have to think about
proper abstractions, *every* client developer has to do the same work in
their own implementation.

The alternative, as shown for Blocking Command above, is that those
simpler use cases are indeed formulated and protocol specific for those
use cases is designed to make things easier to implement *and use* on
the client side, without every client developer having to reinvent the
wheel. A server implementation may still choose to translate that
protocol to privacy lists internally. Or not.

Most of the time, to get people to do something, they need an incentive:
an itch to scratch, a friend, family member, or customer that wants a
certain feature, and/or money. If no-one is indeed willing to come up
with a proposal for those simpler use cases (even if it is just the
protocol exchange on a napkin) than I indeed don't see that ever ending
up as a XEP.

The XSF is in the business of documenting enhancements to XMPP that it
can recommend as good common building blocks for various application
domains. Implementation experience might change how good we think such
a building block might be. And if someone indeed finds it insufficiently
good, they may suggest deprecating it. So far, general consensus seems
to be that Privacy Lists are not awesome, that Blocking Command is a
good alternative for an oft-use use case, and that no one has stepped up
to document alternative protocols for other use cases.

It doesn't require 15 years of prior experience to write a XEP and one
doesn't need to earn special credits for their proposals to be
considered. We do attempt to make sure things are consistent across
various XEPs. We have even written guidelines for protocol design
(XEP-0134: XMPP Design Guidelines) and writing XEPs themselves
(XEP-0143: Guidelines for Authors of XMPP Extension Protocols). If
anyone needs help to get there, shooting off an e-mail with some
suggested protocol exchanges will probably be sufficient to start a
fruitful discussion on this very list.

As I mentioned before, deprecating a 

Re: [Standards] Deprecating Privacy Lists

[Ralph Meijer]

On 2015-10-06 19:24, Evgeny Khramtsov wrote:
> Tue, 6 Oct 2015 11:35:58 -0500
> Sam Whited  wrote:
> 
>> and I doubt that
>> anyone's going to try and come up with a new thing *unless* the old
>> one is deprecated
> 
> The thing is nobody will come up even in the case the XEP is deprecated.
> There were several attempts to write SPIM related XEPs. None of them
> was widely adopted. So we may end up with servers with privacy
> lists disabled and their users unprotected from some sort of attacks.


A little background. After going draft, privacy lists as defined in
JEP-0016 were moved to the first XMPP IM specification (RFC 3921) and
thus deprecated as a JEP. Then, mostly because of the same reasons
(complexity and performance impact), it was dropped for the bis version
(eventually RFC 6121) and reinstated into JEP-0016 in 2006 [*1].

Initially, JEP-0191 (Blocking Command) was introduced as an alternative
that would go into the bis version of the RFC. However, it was decided
that the new RFC would just refer to both JEPs as ways to implement
blocking, as required by RFC 2779 (Instant Messaging / Presence Protocol
Requirements).

So basically, implementors have wanted to get rid of this stuff for
quite a while now.  If nobody comes up with a new specification for
functionality beyond XEP-0191, then my conclusion would be that there is
no sufficient interest. As I said before, the XSF does not generate
specifications that everybody then must implement. It works the other
way around: if there is enough interest in some feature, people will
work on a specification that can then be discussed and accepted by the
Council as a XEP.

Hopefully, such a specification is the result of ongoing experiments
around that feature. If interest dies down and/or fails to get proper
adoption, like happened with your SPIM XEP, it expires. While we can
attempt to steer implementors in a particular direction with Compliance
Suites [*2], even those are not a guarantee that things will get
widespread adoption.

I believe that dropping XEP-0016 is the way forward, and if there are
indeed pressing features that require an alternative, I hope people will
come and start a new, simpler, specification for just that feature and
work together with several implementors to get adoption.

Also note that Deprecated is not the same thing as Obsolete. Deprecation
just says we don't encourage new implementations. Obsolete says that a
protocol should no longer be implemented or deployed. We currently have
3 other Deprecated XEPs and 27 Obsolete ones.

[*1] This was around the same time of changing the naming of JEPs to
 XEPs along with the change of the JSF (Jabber Software Foundation)
 to the XSF.
[*2] Thanks, Sam, for picking that up again.

-- 
ralphm

Re: [Standards] Deprecating Privacy Lists

[Ralph Meijer]

On 2015-10-08 12:52, Evgeny Khramtsov wrote:
> Thu, 8 Oct 2015 12:21:41 +0200
> Ralph Meijer <ral...@ik.nu> wrote:
> 
>> If nobody comes up with a new specification for
>> functionality beyond XEP-0191, then my conclusion would be that there
>> is no sufficient interest
> 
> No. The conclusion also might be that people who want this
> functionality do not write XEPs.
> This is the same as with file-transfer. Obviously everyone wants it,
> but nobody is writing it (at least there is no XEP which fully resolves
> all FT possibilities I listed in previous threads).

Can you explain why people wanting to implement some feature couldn't
(begin to) write a XEP? I believe there are many people on this list who
would be more than happy to help out with such an effort. Peter
Saint-Andre has written dozens of XEPs based on people's first
back-of-the-envelope descriptions of a new protocol. It doesn't have to
be perfect on the first attempt, and it never has been, to be honest.
Once something is written down, it can be discussed and improved upon.

-- 
ralphm

Re: [Standards] XEP-0060: be more consistent with reply #106

[Ralph Meijer]

On 2015-10-05 10:48, Stefan Strigler wrote:
> Hey there,
> 
> when implementing parts of XEP-0060 I came across a maybe inconsistency
> when it's about unsubscribing from a Node (Section 6.2.2
> - http://xmpp.org/extensions/xep-0060.html#subscriber-unsubscribe).
> 
> If we'd allow to also have a the resulting subscription element in the
> response, the implementation can be kept more generic, you always reply
> with the resulting status of the subscription, no matter if it was a
> subscribe or an unsubscribe. 
> 
> Thus my PR at
> 
> https://github.com/xsf/xeps/pull/106
> 
> I am aware that for unsubscribing the additional information given is
> redundant. That's why I changed it to MAY after I first suggested a
> SHOULD there.

Hey Stefan,

While I appreciate the suggestion, if the goal is to make the
implementation more consistent, how would you deal with entities that
don't return that element on the receiving end? Especially given you
suggest making it optional. I'd say that the potential gains are highest
for pubsub clients, but if you can't rely on a server giving that
element always, there's no gain, really. It doesn't even matter that
much if it is a MAY or SHOULD.

-- 
Cheers,

ralphm

[Standards] 18th XMPP Summit -- October 9-10 -- Richland, WA, USA

[Ralph Meijer]

Dear XMPP community,

The XSF is proud to announce the 18th XMPP Summit, which will be held
on October 9–10 in Richland, WA, USA, and colocated with  yetConf
(formerly RealtimeConf), which is October 6–8.

yetConf is focused on the intersections of technology with humanity,
meaning, and ethics. A majority of the Council has already indicated
their intention to be at yetConf, as well as several XSF members.
yetConf tickets include 3 nights hotel, and all meals for 2.5 days,
and are available for XSF members at a discounted price of $1299 using
this link: https://ti.to/yet/conf-2015/with/jywfanjobzk.

For the XMPP Summit, yet will make multiple rooms of meeting space
and whiteboards available at their office. Richland is in the heart of
Washington wine country, so we can also make arrangements for an XSF
Dinner at a local winery, if that's desired. This will be announced
separately.

Official hotel is the mid-century modern Hanford House hotel, located
on the Columbia River.

For those who aren't able to be physically present, we will make it
possible to participate remotely through our XMPP MUC room at
xmpp:sum...@muc.xmpp.org?join, as well as a video conference.

The most up-to-date Summit details can be found at
http://wiki.xmpp.org/web/Summit_18, and announcements and
discussions around the summit will take place on the Summit mailing
list http://mail.jabber.org/mailman/listinfo/summit.

For questions about yetConf, XSF Summit logistics, and (extentions
of) your hotel booking at the Columbia River, contact
mailto:c...@andyet.com. For questions about XSF Summit content,
schedule, and plans, contact Ralph Meijer (mailto:ral...@ik.nu or
xmpp:ral...@ik.nu).

-- 
Cheers,

ralphm

Re: [Standards] Move Carbons to Last Call (Proposed)

[Ralph Meijer]

On August 12, 2015 4:50:18 PM GMT+02:00, Kevin Smith kevin.sm...@isode.com 
wrote:
On 12 Aug 2015, at 15:44, Ralph Meijer ral...@ik.nu wrote:
 
 On August 12, 2015 3:07:44 PM GMT+02:00, Kevin Smith
kevin.sm...@isode.com wrote:
 The thread is moving somewhat away from Carbons Last Calls, but this
is
 all related so I won’t feel too guilty. I have two opinions here:
 [..]
 2) Carbons will need some changes in the (hopefully near) future
once
 the pubsub/account stuff is specced/we have deployment experience. I
 believe this means that going to Draft now wouldn’t be appropriate,
as
 knowing there will be backwards-incompatible changes is at odds with
 the Draft requirement of avoiding such things where possible.
 
 * Does this mean you'd vote -1 if Carbons remains mostly as-is for
now?

For Draft, yes, which is very different to saying I think it has no
merit, or that I don’t think an appropriate version should go to Draft.
Voting something to Draft when I think it’s likely to need further
changes seems inconsistent with xep1.

  * How do you feel such backwards incompatible changes would work out
in practice? I do feel implementors take a risk in putting experimental
specs in production, but also see the high-profile nature of this work
and the bigger context with other IM systems.

I think they’d work out as a new namespace, but I’m not sure. If we
could get the other pieces in place we’d be able to see the bigger
picture and be more confident in these things. I think that MUC2 is not
a prerequisite part of these other pieces for Carbons to be able to
advance, but defining how it interacts with Pubsub/Account seems
necessary. It also seems necessary to include type=normal (I think we
can get away from type=groupchat, thankfully, cleanly in the
MUC2/PubsubAccount approach).

 * Could your envisioned changes be add-on instead? I.e. is there a
chance of future proofing this (now)?

Possibly, but I don’t think we’ve got the picture firm enough yet.

So the question is, do we need to make this spec to be the perfect solution, or 
is Carbons good enough for now?

We've seen a lot of hinting at improvements, and I do remember your own 
suggestions, but I wonder if we couldn't do that in a new spec instead. When 
have we waited long enough to decide this is the best we can do for now?


-- 
ralphm

Re: [Standards] Move Carbons to Last Call (Proposed)

[Ralph Meijer]

On August 12, 2015 3:07:44 PM GMT+02:00, Kevin Smith kevin.sm...@isode.com 
wrote:
The thread is moving somewhat away from Carbons Last Calls, but this is
all related so I won’t feel too guilty. I have two opinions here:
[..]
2) Carbons will need some changes in the (hopefully near) future once
the pubsub/account stuff is specced/we have deployment experience. I
believe this means that going to Draft now wouldn’t be appropriate, as
knowing there will be backwards-incompatible changes is at odds with
the Draft requirement of avoiding such things where possible.

 * Does this mean you'd vote -1 if Carbons remains mostly as-is for now?

  * How do you feel such backwards incompatible changes would work out in 
practice? I do feel implementors take a risk in putting experimental specs in 
production, but also see the high-profile nature of this work and the bigger 
context with other IM systems.

 * Could your envisioned changes be add-on instead? I.e. is there a chance of 
future proofing this (now)?


-- 
ralphm

Re: [Standards] Move Carbons to Last Call (Proposed)

[Ralph Meijer]

On August 12, 2015 5:31:25 PM GMT+02:00, Kevin Smith kevin.sm...@isode.com 
wrote:
On 12 Aug 2015, at 16:14, Ralph Meijer ral...@ik.nu wrote:
 
 On August 12, 2015 4:50:18 PM GMT+02:00, Kevin Smith
kevin.sm...@isode.com wrote:
 On 12 Aug 2015, at 15:44, Ralph Meijer ral...@ik.nu wrote:
 
 On August 12, 2015 3:07:44 PM GMT+02:00, Kevin Smith
 kevin.sm...@isode.com wrote:
 [..]

 We've seen a lot of hinting at improvements, and I do remember your
own suggestions, but I wonder if we couldn't do that in a new spec
instead. When have we waited long enough to decide this is the best we
can do for now?

Well, that was the proposal I made earlier this year, and there was
wide agreement that a new spec was the wrong approach, and waiting for
Carbons was right. I’ve even convinced myself at this point that
waiting for Carbons is probably right.

I don't recall if I was against a competing spec back at the summit, but 
generally believe competing Experimental XEPs are a good thing. Even if yours 
isn't adopted, at least we have an easier-to-find record of it. Digging through 
a heap of mails and chat logs is a lot easier with a XEP number.

Dave - do you have an ETA on the pubsub/Account stuff? I think that
might help matters significantly.

Agreed, although I still believe that stuff is much further in the future as a 
thing to build on.


-- 
ralphm

Re: [Standards] Move Carbons to Last Call (Proposed)

[Ralph Meijer]

On August 12, 2015 11:54:06 AM GMT+02:00, Dave Cridland d...@cridland.net 
wrote:
On 12 August 2015 at 09:01, Georg Lukas ge...@op-co.de wrote:
 The carbon relevant things from that list and from the last 0280
advance
 discussion are:

 * Carbons for non-chat messages. Jingle signalling of incoming
calls
   to all interested clients was mentioned IIRC.


That use-case won't work anyway because Jingle calls are initiated with
an
iq/.

I believe that's his point, that we currently have no way to do this properly. 
As has been suggested before, we may want to do something similar to Message 
Mine-ing (XEP-0259) for that, ahead of the actual Jingle call iq. Presumably 
that could work together with Carbons for the broadcasting bits. 


-- 
ralphm

Re: [Standards] OTR

[Ralph Meijer]

On February 3, 2015 10:37:14 AM WAT, Florian Schmaus f...@geekplace.eu wrote:
On 03.02.2015 10:04, Dave Cridland wrote:
 On 2 Feb 2015 18:49, Peter Saint-Andre - yet pe...@andyet.net
 mailto:pe...@andyet.net wrote:
 On 2/2/15 5:22 AM, Hund, Johannes wrote:
 Since it was undisclosed that even the NSA seems to have problems
 breaking into OTR [1], it gained a lot of attention it seems and
thus
 does a good deal in supporting XMPP as a choice for applications
with
 high requirements in privacy and security as its often the case for
 IoT applications.


 OTR secures only the character data of the XMPP body/ element
within
 message stanzas. That's appropriate for IM but doesn't really help
with
 things like IoT (which often use extended namespaces).

 
 Exactly, and this is the kind of thing I was hoping that documenting
the
 current OTR usage in XMPP would show clearly.

Isn't documenting the current OTR usage in XMPP simply

message …
 body
… put OTR stuff here …
 /body
/message

where OTR stuff is defined at
https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html (I think most
implementations use OTR v2) and
https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html

So OTR is IM protocol-agnostic. You can see how OTR tries to negotiate
using whitespaces at the end of String within the /body element at
https://github.com/python-otr/gajim-otr/issues/9#issue-40676864

I'm also not sure if, not only because it's IM protocol-agnostic, OTR
would be a good fit for IoT. Some research in this direction would sure
be interesting.

- Florian

Sure it will be short. However, some notes on limitations and security 
considerations would also need to be added. If only to make it easier to 
compare against other e2e proposals. If you want to make a start with a XEP, 
that's appreciated.
-- 
ralphm

Re: [Standards] xep-0060 features delete-items and retract-items

[Ralph Meijer]

On 2015-01-08 14:37, Edwin Mons wrote:
 On 08/01/15 14:18, Kurt Zeilenga wrote:
 On Jan 7, 2015, at 9:27 AM, Ralph Meijer ral...@ik.nu wrote:

 On 2015-01-07 16:15, Adrien wrote:
 Hi,

 On 01/07/2015 03:42 PM, Edwin Mons wrote:
 Hi all,

 XEP-0060 lists both delete-items and retract-items for the same feature,
 retract/.  delete-items was added in the last revision, but it looks
 like an error to me.  I think 7.2 should be revised, and one of the two
 features (likely delete-items) should be removed.
 yes you're right. At least that's what I have been told (delete-items
 is the surplus one) when I asked.
 I forget why it was added in the last version of this XEP, but it surely
 wasn't missing as mentioned in the changelog, as we had 'retract-items'
 as a feature for a long time. Reading the text around it, I feel it is
 confusing, too. I'd rather go with talking about 'retracting items' and
 'deleting nodes' thoughout, and not talk about 'deleting items'.

 I think that many (all?) clients ignore this feature for discovery
 altogether, so what about making 'delete-items' a thing that servers
 SHOULD also advertise along with 'retract-items', but have clients
 depend on 'retract-items' exclusively?
 Personally, I rather not add cruft like this.   Has any server ever 
 advertised this?  Has any client ever relied on this?  And, if it’s only 
 SHOULD, no client can rely on it…  Better, IMO, to just require one 
 feature/ to be advertised per feature.

 
 Eh, I've seen delete-items advertised in the wild, because M-Link
 advertises it.

Hi,

Edwin also tells me he has been working on this, but M-Link doesn't
currently advertise the (older and IMO proper) feature called
retract-items. Idavoll only sends the latter, and Prosody sends both. I
haven't done a thorough check on other implementations.

As such, my suggestion was meant to be an attempt to have backwards
compatibility, which I am a strong supporter of.

That said, I've not found evidence of clients having their use of the
retract protocol depend on either of these features being advertised.

Finally, I'm not convinced that retraction should be RECOMMENDED, and
think the current registration of retract-items being OPTIONAL is just fine.

-- 
ralphm

Re: [Standards] xep-0060 features delete-items and retract-items

[Ralph Meijer]

On 2015-01-08 14:52, Kurt Zeilenga wrote:
 
 On Jan 8, 2015, at 5:37 AM, Edwin Mons j...@edwinm.ik.nu wrote:

 On 08/01/15 14:18, Kurt Zeilenga wrote:
 On Jan 7, 2015, at 9:27 AM, Ralph Meijer ral...@ik.nu wrote:

 On 2015-01-07 16:15, Adrien wrote:
 Hi,

 On 01/07/2015 03:42 PM, Edwin Mons wrote:
 Hi all,

 XEP-0060 lists both delete-items and retract-items for the same feature,
 retract/.  delete-items was added in the last revision, but it looks
 like an error to me.  I think 7.2 should be revised, and one of the two
 features (likely delete-items) should be removed.
 yes you're right. At least that's what I have been told (delete-items
 is the surplus one) when I asked.
 I forget why it was added in the last version of this XEP, but it surely
 wasn't missing as mentioned in the changelog, as we had 'retract-items'
 as a feature for a long time. Reading the text around it, I feel it is
 confusing, too. I'd rather go with talking about 'retracting items' and
 'deleting nodes' thoughout, and not talk about 'deleting items'.

 I think that many (all?) clients ignore this feature for discovery
 altogether, so what about making 'delete-items' a thing that servers
 SHOULD also advertise along with 'retract-items', but have clients
 depend on 'retract-items' exclusively?
 Personally, I rather not add cruft like this.   Has any server ever 
 advertised this?  Has any client ever relied on this?  And, if it’s only 
 SHOULD, no client can rely on it…  Better, IMO, to just require one 
 feature/ to be advertised per feature.


 Eh, I've seen delete-items advertised in the wild, because M-Link
 advertises it.
 
 Yeah but for how long?
 
 My view is that while it might be nice continue advertising delete-items for 
 clients which tried to adhere to XEP 60 as it’s written, adding a SHOULD here 
 turns what is intended to reduce interop issues into a long term interop 
 issue.   Better, IMO, to leave it out of the spec.   Server implementors will 
 likely continue to advertise delete-items for some reasonable period of time 
 without the SHOULD…. and that enough to give client implementors enough time 
 (years) to move to proper feature name.
 
 But, over all, not all that big of deal.   Nothing I feel like I need to fall 
 on sword for.

Sure, based on current evidence, the impact of just dropping that
feature name is zero in practice. I was hoping for other people speaking
up with additional data.

-- 
ralphm

Re: [Standards] xep-0060 features delete-items and retract-items

[Ralph Meijer]

On 2015-01-07 16:15, Adrien wrote:
 Hi,
 
 On 01/07/2015 03:42 PM, Edwin Mons wrote:
 Hi all,

 XEP-0060 lists both delete-items and retract-items for the same feature,
 retract/.  delete-items was added in the last revision, but it looks
 like an error to me.  I think 7.2 should be revised, and one of the two
 features (likely delete-items) should be removed.
 
 yes you're right. At least that's what I have been told (delete-items
 is the surplus one) when I asked.

I forget why it was added in the last version of this XEP, but it surely
wasn't missing as mentioned in the changelog, as we had 'retract-items'
as a feature for a long time. Reading the text around it, I feel it is
confusing, too. I'd rather go with talking about 'retracting items' and
'deleting nodes' thoughout, and not talk about 'deleting items'.

I think that many (all?) clients ignore this feature for discovery
altogether, so what about making 'delete-items' a thing that servers
SHOULD also advertise along with 'retract-items', but have clients
depend on 'retract-items' exclusively?

-- 
ralphm

Re: [Standards] Veto on Privileged Entity

[Ralph Meijer]

On 2014-12-17 14:24, Kurt Zeilenga wrote:
 [..]
 It seems you are holding this ProtoXEP hostage for a general discussion
 and possibly more (“a better system”?).

Hi,

I haven't fully digested all words in this thread. However, I think I
understand the general idea of the arguments being made by (mostly) Dave
and Kurt.

My general approach to accepting proto-XEPs into our XEP series has
always been:

 * Is the problem this proposal aims to find a solution for general
   enough that it is reasonable to standardize it within the XSF?

 * Does the proposal make general sense, without going into details?

I specifically tried to avoid digging into (potential) implementation
obstacles or protocol specifics /for the purpose of (not) objecting to
the publication of the proposal/. Naturally any such comments would
still be conveyed along with the non-objection.

In my view, publication of a specification as an Experimental XEP is the
*start* of a discussion on the proposal, and mostly everything within
the document is subject to scrutiny and change before moving forward in
our standards process.

Dave rightly raises a bunch of problems one might encounter while trying
to get this implemented in existing code bases, mostly following from
the lack of a coherent idea of modeling objects, permissions, etc., in
already accepted (and widely used) protocols.

I agree that this should be addressed. I don't agree that this should be
a per-requisite for the publication of this specification. I am pretty
sure that implementation experience will prove Dave right in some of the
aspects raised, and that's fine, because that gives people a better
understanding of what's needed.

I want to note that there is only a (very) small subset of contributors
in our community that can grasp the entirety of our protocol suite from
implementation experience. If this is required to get proposals accepted
(hyperbole much), we are doing it wrong.

On the other hand, we (the community, lead by the Board and Council)
have an obligation to inform and educate people new to our community on
how to present and work on proposals they might have, so that they at
least have a chance of moving forward. But also, make it very clear that
experimental XEPs might not have received the 'full treatment' of
scrutiny yet, and are thus not (yet) 'ready' for general use.

There have been suggestions to move such scrutiny forward, but in my
opinion that just creates a congruent situation, with the difference of
not having a number for such proposals.

-- 
Cheers,

ralphm

Re: [Standards] Last call XEP-0322 XEP-0332

[Ralph Meijer]

On 2014-11-13 15:59, Peter Waher wrote:
 Hello everybody
 
  
 
 Sorry for being out of touch and not having responded to the many mails.
 I’ve been overwhelmed by work, and have had to focus on certain things
 to be able to clear things up. It is my plan to retake the effort,
 review all input made to the standards list, and update the
 corresponding XEPs and answer all feedback in a couple of weeks. I hope
 that is OK. Sorry again for the delay, and thanks for the effort and all
 input.

Thanks for the update Peter!

-- 
ralphm

Re: [Standards] OTR

[Ralph Meijer]

On 2014-11-14 22:25, Genghis Khan wrote:
 On Sun, 09 Nov 2014 10:46:58 +0100
 Winfried Tilanus winfr...@tilanus.com wrote:
 
 On 07-11-14 15:39, Stefan Strigler wrote:

 Hi,

 But will you mention http://thealiceandbobsuicide.org ? 

 That is quite a dilemma, you know, I am still missing Alice and Bob...

 Winfried
 
 Who are Alice and Bob?
 
 Bobs Suicide Letter has a typo an horrible.

As always, that depends on your pronunciation [1,2].

[1]
http://www.oxforddictionaries.com/words/why-do-such-words-as-hour-and-honest-have-a-silent-h
[2]
http://en.wikipedia.org/wiki/English_articles#Distinction_between_a_and_an

-- 
ralphm

Re: [Standards] IOT-Events

[Ralph Meijer]

On 2014-09-26 15:26, Kevin Smith wrote:
 Hi folks,
   I promised to see if I could think of something sensible to say
 about IOT-Events.
 
 My core concern here is that this spec
 (http://xmpp.org/extensions/inbox/iot-events.html) is designed such
 that one entity can publish events, to which assorted other entities
 can subscribe, which fundamentally sounds like pubsub, for which we
 have some coverage in XEP-0060. IOT-Events comes up with a completely
 new syntax for both the subscribing and the publishing from that
 described in XEP-0060, and I'd like to see if there is common ground
 for sharing syntax (and, ideally, semantics).
 
 I note at this point that re-use of XEP-0060 syntax would not imply
 the use of central pubsub services on components or servers. In
 IOT-Events, a Thing is its own (IOT-Events)pubsub service; I'm
 interested in seeing if they could be their own (XEP-0060
 subset)pubsub service instead.

I like this general approach!


 I suggest we define a standard form that can hold the subscription
 options in IOT-Events, so example 1:
 
  iq type='get'
from='cli...@clayster.com/amr'
to='dev...@clayster.com'
id='S0001'
   subscribe xmlns='urn:xmpp:iot:events' seqnr='1'
 momentary='true' maxInterval='PT5M' req='true'/
/iq
 
 would become something a bit like
 
  iq type='get'
from='cli...@clayster.com/amr'
to='dev...@clayster.com'
id='S0001'
   pubsub xmlns='http://jabber.org/protocol/pubsub'
 
 subscribe
 node='somethings'
 jid='cli...@clayster.com/amr'/
 options
   x xmlns='jabber:x:data' type='submit'
 field var='FORM_TYPE' type='hidden'
   valuehttp://jabber.org/protocol/pubsub#subscribe_options/value
 /field
 field var='iot#seqnr'value1/value/field
 field var='iot#momentary'valuetrue/value/field
 field var='maxInterval'valuePT5M/value/field
 field var='pubsub#deliver'value1/value/field
   /x
 /options
   /pubsub
/iq
 
 These fields can be standardised in IOT-Events such that discovery is
 not necessary, and the number of roundtrips remains the same.

A few things here, where I'll refer to XEP-0060 (Publish-Subscribe)
version 1.13, as a bunch will move out of XEP-0060 post-split.

1) If I read iot-events correctly, it appears that an entity can have
multiple subscriptions to the same 'device'. I see this example uses the
node 'somethings'. The combination of these results in the following
questions:

  1a) How would node identifiers be used in this context? I note that
  XEP-0323 has the concept of node identifiers. Do these map to general
  concept of nodes we have in XEP-0060 and also service discovery
  (XEP-0030)?

  If so, I note that the attribute used in XEP-0323 (IoT Sensor Data)
  should really be called 'node' and not 'nodeId' for consistency. If
  not, it should receive a different name than 'node'. I have more beef
  with attribute/element naming in XEP-0323 in general, but that's
  probably out of scope for this exchange.

  1b) Can an entity have more than one subscription to the same
  node/device/entity?

  1c) Or, alternatively, will there be a single node identifier (maybe
  the empty one, also called root node) and will subscriptions be
  content based rather than topic based? Or a combination of such maybe,
  where this is like Collections (XEP-0248), but with just a single
  collection at the root.

2) Is 'seqnr' as currently proposed not exactly like the subscription
identifier in Content-based Subscriptions as defined in section 12.19 of
XEP-0060 [1]?

3) I want to remark the fields in the example of the form are not named
like we want them to look eventually (see XEP-0068). It would be more like:

  x xmlns='jabber:x:data' type='submit'
field var='FORM_TYPE' type='hidden'
  valuehttp://jabber.org/protocol/pubsub#subscribe_options/value
/field
field var='{urn:xmpp:iot:sensordata}seqnr'
  value1/value
/field
field var='{urn:xmpp:iot:sensordata}momentary'
  valuetrue/value
/field
field var='{urn:xmpp:iot:sensordata}maxInterval'
  valuePT5M/value
/field
field var='pubsub#deliver'value1/value/field
  /x

[1] http://xmpp.org/extensions/xep-0060.html#impl-content

-- 
ralphm

Re: [Standards] XEP-0045 to Final?

[Ralph Meijer]

On 2014-03-05 11:16, Christian Schudt wrote:
 Hi,
 
 could you elaborate on this proposal a little bit, please?

Agreed. I'm a more of a fan of publish-subscribe than the next guy, but
I don't see how this is a helpful suggestion without elaboration.

Going back to the original question, I don't think that service
discovery on room items (usually occupants) is restricted to occupants.
A service may also answer this for registered members.

However, I do see that section 6.6 (Querying a Room Occupant) is rather
short. In any case, querying an occupant would pass the query to the
real JID, and I'm not sure if you could actually discover the real JID
itself that way. The MUST for non-occupants seems excessive, and I don't
see why you shouldn't be able to do service discover as a non-occupant
member, admin, or owner.

 It would be so much easier to just allow 7.11 Getting the Memberlist also for 
 the Entity Use Cases, so that an entity could just query a room for it's 
 members (without having joined the room):

Agreed. Reading the text there, I think MUC servers MAY actually support
that. It doesn't explicitly limit it to occupants or admins.

-- 
ralphm

Re: [Standards] XEP-0045 to Final?

[Ralph Meijer]

On 2014-03-05 12:48, Winfried Tilanus wrote:
 [..] 
 Well, I *assumed* your MUC implementation did not support this.
 
 Assuming that, you can try to change your MUC implementation (leaving
 alone the question if a change to XEP-0045 is needed). But when you have
 to change your MUC implementation, you may consider to hook into the
 pubsub infrastructure: that infrastructure leaves much more room for
 creating data nodes for providing the data you need.

There's a huge difference in allowing existing protocol be used in more
expanded use cases (like requesting a room's member list) and adding an
entire protocol suite to an existing implementation.

Also, if I look at Christian's use case, he is simply trying to work on
the common multi-user chat protocol. I'd assume that backwards
compatibility with existing clients is at least preferred, if not
requirement. So re-using MUC makes a lot of sense.

And sure, if we were to start over, we might have built MUC on top of
the publish-subscribe protocols. The current MUC protocol has its warts
and dark corners, but a full-scale replacement (possibly on top of
pubsub) is simply not going to happen. And, contrary to popular belief,
pubsub is not the be-all and end-all of all things XMPP. At most, we can
'evolve' parts of the MUC protocol with backwards compatibility in mind.

And with that I made a bridge to my intended contribution to this thread
about bringing XEP-0045 to Final. I do see places of improvement to our
current protocol for MUC. I chatted with a few people on this in
Brussels and it might be useful to just jot it down here:

 1) Redo the room join protocol with IQs. You'd simply send an IQ to the
room JID (as opposed to an occupant JID) and send presence there,
too. This basically gets you to a new-style mode.

 2) Use opaque identifiers for the resource part of occupant JIDs.

 3) Display names (nicks) are just one property of an occupant,
orthogonal to being in the room. It might that you could request a
display name when joining a room or that it is something you
register if you have an affilitation with the room. We could define
protocol for changing nicks. It might be that display names come
from your roster or occupant vCards.

I want to note that Google Talk's MUC support (before new Hangouts) did
something similar. Because of the way it handled directed presence and
how directed presence relates to current-MUC-join, this caused issues
with nick changes and other things.

The above might improve the brittleness of using presence for room
joins/unjoins. It would also allow for a mode where you are in the room,
receiving/sending messages, but not interact in the presence exchange.
Over the years I've seen several use cases that would benefit from that.

Nothing of the above would impede a move of XEP-0045 to Final, by the way.

-- 
ralphm

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Ralph Meijer]

On 2013-11-18 13:07, Andreas Kuckartz wrote:
 Simon Tennant:
 IMHO, e2e security would probably make more sense as a XEP and working
 group that has the time to zoom into all the implementation details.
 
 Can that be solved by an XEP ?
 
 What about this IETF draft? (I still have to read it)
 
 End-to-End Object Encryption and Signatures for the Extensible Messaging
 and Presence Protocol (XMPP)
 draft-miller-xmpp-e2e-06
 https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/
 
 There exist people who mention XMPP as belonging to faulty
 technologies for which they want to create alternatives:
 http://youbroketheinternet.org/

From a first glance, it looks like some PSYC proponents are involved
with this. Here is their stand on the brokenness of XMPP:

http://about.psyc.eu/Jabber

Also, hi fippo!

-- 
ralphm

Re: [Standards] Suggestions for updates to XEP-0071: XHTML-IM

[Ralph Meijer]

On 2013-11-06 13:41, Peter Waher wrote:
 Hello Ralph
 
 What could be required is to support the markup (and not reject the 
 XHTML as a whole), and either be able to render a small subset or use 
 a valid fallback mechanism (as that explained in Example 8 in the 
 extension).

 The fallback mechanism is already well-defined and required by section 12.2.
 
 Yes, I know there's a fallback mechanism defined, but I believe when it comes 
 to tables that fallback mechanism might be unfortunate: First it would join 
 cell contents. Some spacing or separation between cells horizontally would be 
 in order (even though column margins cannot be maintained). And a br/ 
 between rows would also be necessary to make sure different rows in the table 
 end up on different rows in the output.

I guess those are the breaks. Either you support tables, or you don't.
Of course clients supporting tables might need to do suboptimal
rendering (e.g. terminal-based clients), but that doesn't count as a
fallback mechanism, to me. I'd rather not specify how tables are
rendered in clients at all.

-- 
ralphm

Re: [Standards] Suggestions for updates to XEP-0071: XHTML-IM

[Ralph Meijer]

On 2013-11-04 21:55, Peter Waher wrote:
 Hello all
 
  
 
 I have some suggested additions to the XHTML-IM extension XEP-0071
 (which is still in Draft). [..]
 
 Tables are explicitly forbidden in the current version for the following
 reasons [..]

Forbidden seems a particularly strong interpretation. To be clear, the
specification says:

 Any other elements and attributes defined in the XHTML 1.0 modules
that are included in the XHTML-IM Integration Set SHOULD NOT be
generated by a compliant implementation, and SHOULD be ignored if
received [..]

Specialized application could implement support for tables if they want.
However, …

 This sounds like an unnecessary restriction probably stemming from the
 fact that “instant messaging” equates human-to-human chat applications
 to many people. However, XMPP is obviously much more than that.
 
 There are many examples were the support for tables would actually be
 very beneficent, especially in human-to-machine chat applications, i.e.
 chatting with robots. (Machine-to-machine is obviously solved using XML
 and not text.) A robot often needs to return tabular information, for
 instance, voting results, to take an example that all XSF-members knows.

… while I'm sympathetic to the argument of machine-to-human interaction,
I question the claim to tabular information needing to be returned
*often*. Ivan's suggestion of having a separate XEP for representing
tabular data, similar to Data Forms, is interesting. So far nobody has
expressed a need for that, though. Also, this is the first requirement
of XHTML-IM:

 1. IM clients are not XHTML clients: their primary purpose is not to
read pre-existing XHTML documents, but to read and generate relatively
large numbers of fairly small instant messages.

While not stated explicitly, this mostly assumes human-to-human
interaction as the /primary/ use case.

Partly playing devil's advocate, my arguments counter your proposal are:

 1) Current implementations already have a hard time correctly
implementing a limited subset of XHTML and seeminly just throw whatever
they get in at an HTML rendering widget. At the Summit two weeks ago we
had a great presentation on this, highlighting the security risks
involved with not whitelisting (as opposed to blacklisting) elements,
attribute names, values and CSS constructs. Your example of PSI
supporting tables may be a bug :-/

 2) Allowing tables in this context opens another door to lenghty
stanzas. As you mentioned in the context of images, large stanzas
effectively block a connection for other stanzas.

 3) I don't think I have ever felt the need for including tabular
information directly in e-mails, let alone IM exchanges. I'd probably
refer to an external document instead.


 Support for a basic set of table support is thus warranted in
 IM-clients. The most basic would be support for table, tr and td,
 perhaps also with th. If colspan and rowspan attributes are seen as
 difficult to implement, they could be omitted. The important aspect here
 is to be able to output textual information in columns. The text-align
 attribute would be a bonus, but not required.

If we were to add support for this, I'd suggest using the Basic Tables
Module as defined in [1], possibly restricted further by excluding most
attributes.


   Data URI scheme
 
 Rephrasing §7.5, regarding support of data URI scheme in IMG tags. It
 says its use is “not recommended”. However, it could state that use by
 sender is not recommended for the reasons listed (i.e. possible large
 stanzas), but support for the URI scheme in the receiver should still be
 recommended (but not required), if somebody uses it anyway (i.e. it is
 not forbidden).
 
 http://xmpp.org/extensions/xep-0071.html#profile-image

I disagree strongly with changing this. Also, again, it is not forbidden
to support this.


   HTTPX support
 
 An important aspect of IMG tags is the ability to fetch images from
 anywhere reachable by an URL. However, publishing dynamic content in an
 XHTML layout might be difficult using HTTP-URLs, especially if the
 sender is not reachable from the client (i.e. lies behind a firewall).
 Optional methods for sending images over XMPP exist, but they cannot (?)
 be combined with XHTML and the IMG-tag.

SI File Transfer (XEP-0096) defines XMPP URI support for retrieving
files by name [1]. We could define something similar for Jingle File
Transfer.


 However, the new extension HTTP over XMPP (XEP-0332) solves this by
 defining a new URI scheme: *httpx*. A reference to XEP-0332 would be in
 order from §7.5 (Image Module Profile) stating that images can be
 transferred using URLs if support for the httpx URI scheme is available
 by both sender and receiver.

As stated before, I am not convinced of the usefulness of layering HTTP
on top of XMPP in general, and the proposed new URI scheme in
particular. I think Tomasz Sterna expressed this well [2].

[1]
http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#sec_5.6.

Re: [Standards] Suggestions for updates to XEP-0071: XHTML-IM

[Ralph Meijer]

On 2013-11-05 13:53, Peter Waher wrote:
 [..]
 I would however *not* explicitly require support for tables, as that
 would imply no IM client could be considered properly compatible with
 the XEP-0071 without support for rendering HTML tables. 
 
 What could be required is to support the markup (and not reject the
 XHTML as a whole), and either be able to render a small subset or use a
 valid fallback mechanism (as that explained in Example 8 in the extension).

The fallback mechanism is already well-defined and required by section 12.2.

-- 
ralphm

Re: [Standards] Proposed XMPP Extension: JSON Containers

[Ralph Meijer]

Please don't top post. Reformatted below.

On 2013-10-09 18:58, DOI Yusuke wrote:
 On 2013-10-09 18:46, Maxim Ignatenko wrote:
 On 9 October 2013 16:20, XMPP Extensions Editor edi...@xmpp.org wrote:
 Abstract: This specification defines an element to be used for
encapsulating JSON data in XMPP.

 What's the intended purpose of embedding JSON into XMPP stanzas?
 Provide a standard encapsulation for things like Google Cloud
 Messaging?

 I feel it's better to define a standard method to encode arbitrary
 content type content type=text/json{}/content than defining
 json tag specifically to say 'this is JSON'.
 (I'm not sure if there are such spec already or not)

First off, arbitrary content cannot be represented in XMPP like that, as
it doesn't embed binary data nicely. But see Justin's reply for that, as
well.

The primary use case for me is in publish-subscribe. There, you must
have a containing element for item payloads, and specifying one
dedicated to JSON makes a lot of sense to me. If you read today's
article by Justin [1], you can easily see why.

As mentioned in the comments over at HN [2], if you want to make things
easy for (web-)developers that like to deal with simple APIs without
having to craft XML for payloads this really helps. Now the API is
basically a destination address for the Publish-Subscribe service, a
node identifier, optionally an item identifier and the payload as JSON.
Doing a generic content/ with mime type and encoding seems over-design.

-- 
ralphm

Re: [Standards] Proposed XMPP Extension: JSON Containers

[Ralph Meijer]

On 2013-10-09 19:45, Ralph Meijer wrote:
 Please don't top post. Reformatted below.
 
 On 2013-10-09 18:58, DOI Yusuke wrote:
 On 2013-10-09 18:46, Maxim Ignatenko wrote:
 On 9 October 2013 16:20, XMPP Extensions Editor edi...@xmpp.org wrote:
 Abstract: This specification defines an element to be used for
 encapsulating JSON data in XMPP.

 What's the intended purpose of embedding JSON into XMPP stanzas?
 Provide a standard encapsulation for things like Google Cloud
 Messaging?

 I feel it's better to define a standard method to encode arbitrary
 content type content type=text/json{}/content than defining
 json tag specifically to say 'this is JSON'.
 (I'm not sure if there are such spec already or not)
 
 First off, arbitrary content cannot be represented in XMPP like that, as
 it doesn't embed binary data nicely. But see Justin's reply for that, as
 well.
 
 The primary use case for me is in publish-subscribe. There, you must
 have a containing element for item payloads, and specifying one
 dedicated to JSON makes a lot of sense to me. If you read today's
 article by Justin [1], you can easily see why.
 
 As mentioned in the comments over at HN [2], if you want to make things
 easy for (web-)developers that like to deal with simple APIs without
 having to craft XML for payloads this really helps. Now the API is
 basically a destination address for the Publish-Subscribe service, a
 node identifier, optionally an item identifier and the payload as JSON.
 Doing a generic content/ with mime type and encoding seems over-design.

[1] http://blog.fanout.io/2013/10/09/publishing-json-over-xmpp/
[2] https://news.ycombinator.com/item?id=6520524

-- 
ralphm

Re: [Standards] XMPP Standards Foundation and XEP-0001

[Ralph Meijer]

SM s...@resistor.net wrote:
Hello,

According to XEP-0001:

The XMPP Standards Foundation (XSF) adheres to an open standards
process

I browsed through the www.xmpp.org web site.  I found some meeting 
minutes at http://xmpp.org/about-xmpp/xsf/meeting-minutes/  The 
minutes for the past year is basically voting results.  Is XSF still 
operational and if so, is there any requirement for it to operate in 
a transparent manner?

Hi,

Well, voting is just about the only thing we do in general member meetings. The 
minutes generally also link to the raw chat logs.

The rest of the activities of the XSF is working on (improving) our standards. 
The primary body for this is the Council along with everybody on the standards 
list. Council meetings are also open, and, again, raw chat logs are available. 
There is also a Council mailing list.

Finally, there is the Board, which takes care of the organizational stuff 
regarding the Foundation: finance, planning summits, managing voting, and 
steering our 'teams'. Board meetings are open, and take place in 
xmpp:x...@muc.xmpp.org, just like member meetings, and also logged. Most of 
the XSF discussion happens on the members mailing list.

I do notice that out website doesn't clearly show where the XSF MUC room 
archives are. That's something we should address.

You can find the specifics on our obligations in the by-laws, but yes, we try 
to be as transparent as we can be. If you have any further questions, let us 
know!

Thanks!


-- 
ralphm

Re: [Standards] Heml.is and federation..

[Ralph Meijer]

On 2013-07-12 20:56, Steffen Larsen wrote:

Hi,

I just stumbled upon https://heml.is, which is a new XMPP client for IOS and 
Android. Anyone knows these guys?

It uses XMPP and PGP for encryption, but do any of you guys know if they 
federate?.. What I can see from skimming their page, its yet another silo, due 
to the fact of PGP and their own infrastructure.
So federation and using your own domain does not seem feasible, right? Anyone 
want to discuss this and the alternatives besides OTR? Security labels?

When I see something like this I get exited to start with because I actually 
want something like this on the client/server part, but then later on gets down 
to earth when it seems out of the standards. Or is it just me?


I think the most interesting aspect of projects like this is the 
addition of some form of end-to-end encryption. If you want to be 
involved in an effort like this, I strongly recommend you get on the 
IETF XMPP WG mailing list and discuss Matt Miller's draft [1].


This is basically the result of several attempts to standardize e2s 
encryption for XMPP. It needs more eyes, implementations and feedback.


[1] http://tools.ietf.org/html/draft-miller-xmpp-e2e-06

--
ralphm

Re: [Standards] XMPP URI usage in HTTP over XMPP

[Ralph Meijer]

On 2013-07-10 22:27, Dave Cridland wrote:

  So, to be able to create such a seamless transition (which is also
important in semantic web scenarios) we need an URI scheme that works in
a syntactically identical manner as the already existing http URI
scheme. Now, there exists another such URI scheme, which shows how this
is best done: the https URI scheme. Basically it's the same problem: How
to create a new transport of HTTP messages, but maintaining URI syntax
logic available in clients.

I wonder, though, what other options would satisfy.

Given http://example.org/, could we have a browser which understood
HTTP/XMPP transition seamlessly to fetching from an XMPP entity instead?

Also, my impression based around a quick read rather than detailed
review is that this is a simple mapping of HTTP/1.1 to an XMPP
transport; I wonder if this should be examined in the light of the
advances present in HTTP/2.0 (AKA SPDY).


Do you mean just using XMPP as the actual protocol dereferencing normal 
http(s) URIs? Interesting thought.


--
ralphm

Re: [Standards] XMPP URI usage in HTTP over XMPP

[Ralph Meijer]

Peter Saint-Andre stpe...@stpeter.im wrote:
hat type='registrar'/

On 7/9/13 9:53 PM, Peter Waher wrote:
 Hello Ralph
 
 Thanks for your mail. You're absolutely correct. It was sloppy of me
 to propose a URI scheme with the same name as the previous xmpp
 scheme. I'm sorry.
 
 [ .. ]
Defining a new URI scheme is not an effort to be taken lightly. Please
see RFC 4395, in particular Section 2.1:

 [..]

Does your proposal pass that test?

I agree with Peter. Just introducing a new scheme doesn't feel right to me. At 
the very least I'd like to see a rational for not using the xmpp scheme, which 
should be able to handle the use cases, that goes beyond the lack of 
character-by-character equivalence after the scheme component, compared to 
HTTP(S) URIs.


-- 
ralphm

[Standards] XMPP URI usage in HTTP over XMPP

[Ralph Meijer]

Hi,

The usage of the xmpp URI scheme in the HTTP over XMPP proposal does 
not conform to the syntax and semantics defined in RFC 5122. In the 
following I will use URI terminology as defined in RFC 3986 (URI: 
Generic Syntax) to explain how XMPP URIs are structured.


The syntax of any URI is as follows:


 foo://example.com:8042/over/there?name=ferret#nose
 \_/   \__/\_/ \_/ \__/
  |   ||||
   scheme authority   pathquery   fragment
  |   _|__
 / \ /\
 urn:example:animal:ferret:nose

In XMPP URIs, we the define the different components as follows:

 * The authority component is used to denote the entity to authenticate
   as (localpart@domain), before processing the rest of the URI.
 * The path component is the target entity to be communicated with.
 * The query component is for specific interaction semantics and
   subaddressing.

Usually, the authority component is omitted. In this case, the entity 
used for authentication is not specified, and assumed to be whatever the 
processing application chooses from its configuration. An example is:


xmpp:ral...@ik.nu

This is just a reference to my JID. Another example includes a suggested 
interaction:


xmpp:ral...@ik.nu?message

The result of clicking on a link pointing to the URI above could be 
opening up a message entry dialog to send a message to my JID, using a 
pre-defined account (or allowing the user to select on in the dialog).


However, if a specific entity is required to be used for authentication, 
an authority component may be included:


xmpp://gu...@example.com/ral...@ik.nu?message

This requires the application to connect to example.com, authenticate as 
gu...@example.com and then send the message upon completing the dialog.



Back to HTTP over XMPP, I believe that in general, an authority 
component is not required. One of the examples in the pro-XEP made into 
a proper XMPP URI would probably look like this:


   xmpp:httpser...@clayster.com/api?;p1=ap2=b

Note that due to hysterical reasons, there is a semicolon directly 
following the question mark. The space in between is reserved for 
specifying the so-called querytype, as registered with the XMPP 
Registrar [1]. An example is:


   xmpp:pubsub.ik.nu?pubsub;node=test

This points to a Publish-Subscribe node named 'test'.

It might be useful to define such a querytype for HTTP over XMPP, too.


[1] http://xmpp.org/registrar/querytypes.html

--
ralphm

Re: [Standards] Fwd: Re: [Netconf] XMPP as transport

[Ralph Meijer]

On 2013-07-03 22:17, Peter Saint-Andre wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

FYI, yet more potential customers for XMPP. Join the IETF NETCONF
list if you're interested.


Indeed. Michal Vaner recently wrote [1] to this list about that effort, too.

[1] http://mail.jabber.org/pipermail/standards/2013-May/027582.html

--
ralphm

Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)

[Ralph Meijer]

On 2013-06-13 09:06, Philipp Hancke wrote:

[..]
The use of trickle might be interesting... basically that would be the
example from
http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00#section-4
(note that m-line-id should be mid there)


Please, do not copy examples, but create new ones. There might be legal 
issues.


--
ralphm

Re: [Standards] Proposed XMPP Extension: SIP/SDP Over XMPP (SoX)

[Ralph Meijer]

On 2013-06-13 15:48, Alexey Melnikov wrote:

On 13/06/2013 12:35, Ralph Meijer wrote:

On 2013-06-13 09:06, Philipp Hancke wrote:

[..]
The use of trickle might be interesting... basically that would be the
example from
http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00#section-4

(note that m-line-id should be mid there)


Please, do not copy examples, but create new ones. There might be
legal issues.

Why are you saying this?


Just like the IETF, the XSF relies on copyright assignment. In general 
it is preferable to use original work in all cases.



 I thought copying examples from RFC or IETF drafts is fine.

Because the XSF operates outside of the IETF, other provisions of the 
Trust Legal Provisions (TPL) [1] apply. I.e. for those documents that 
are governed by it.


In this particular case, see section 3c. We'd have to make sure proper 
attribution, legends and all that are included, which goes /slightly/ 
beyond copy/paste.


[1] http://trustee.ietf.org/license-info/

--
ralphm

Re: [Standards] ProtoXEP offered; google:queue

[Ralph Meijer]

On 2013-05-23 16:55, Dave Cridland wrote:

On Thu, May 23, 2013 at 3:49 PM, Peter Saint-Andre stpe...@stpeter.im
mailto:stpe...@stpeter.im wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 5/23/13 1:55 AM, Dave Cridland wrote:
  The timing's now reached the perfect level of irony, I think.

It's not clear to me that the XSF can legitimately publish other
people's extensions, or that third parties can submit other people's
extensions. I'm all for documentation, but we might not be able to do
that in the XEP series.


It's not clear to me why not.

We certainly couldn't if this were lifting text from someone else's
documentation - it's not - it's merely documenting an XMPP extension,
and as far as I'm aware there is no restriction on our doing so - it's
purely a copyright issue.


Two reasons I can come up with are copyright and patents on the protocol 
itself. I'm not sure in which jurisdictions copyright is applicable 
and/or enforcible to protocol, but at least the US and the EU seem to 
have provisions for this particular case [1]. Patents, well, there might 
be dozens of patents covering our existing protocols. I don't want to 
know about those, if I can help it.


On top of that, our own ventures in this area, SIFT specifically, are 
functionally equivalent and/or overlapping.


[1] http://en.wikipedia.org/wiki/Reverse_engineering#Legality

--
ralphm

Re: [Standards] XEP 202

[Ralph Meijer]

On 2013-05-22 12:22, Sergey Dobrov wrote:

Hello,

Don't you forget to specify user's resource in the to iq's attribute?


This is a very good point. Let me clarify.

If you send iq/ stanzas to a user's bare JID, these are to be handled 
by the server on behalf of the user. It makes sense that the server just 
responds with its view on time. However, if you send it to a specific 
resource, the stanza should be handled by a client, hopefully giving you 
its view on time instead.


--
ralphm