Re: [Standards] Proposed XMPP Extension: Stanza Content Encryption

[Dave Cridland]

On Mon, 24 Jun 2019 at 20:46, Florian Schmaus  wrote:

> On 24.06.19 19:04, Ненахов Андрей wrote:
> > пн, 24 июн. 2019 г. в 21:59, Georg Lukas :
> >> 1. I'd like to see certain fields of the  being REQUIRED,
> >> especially:
> >>
> >> - the from address
> >
> > So much for deniability.
>
> You usually only need 'from' if you also sign the data, and then
> deniability is already gone. And if you do not sign the data, then the
> 'from' attribute carries no meaning and is actually harmful because an
> erroneous implementations could assume its value is genuine.
>

I think if you encrypt the data without a way to identify the sender, it's
not very interesting. But a system that encrypts, and then signs, as
distinct steps would mean that an attacker could resign a message, so a
"from" might be useful there.

But in no case does this mean deniability is affected. It might mean
anonymity is, though, in MUC for example.

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

Re: [Standards] Proposed XMPP Extension: Stanza Content Encryption

[Dave Cridland]

On Mon, 24 Jun 2019 at 17:58, Georg Lukas  wrote:

> * Jonas Schäfer  [2019-06-19 17:00]:
> > Title: Stanza Content Encryption
>
> This was long overdue.
>
> Some ideas for consideration:
>
> 1. I'd like to see certain fields of the  being REQUIRED,
> especially:
>
> - the from address
> - maybe, possibly, the recipient address(es)
> - a  (or ) element
> - the @id / origin-id
>
> The @id can be used for deduplication of the content, from/to can be
> used to check whether an encrypted message was forwarded by an attacker
> and the  element ensures that replay attacks become visible.
>
>
I'm assuming these comments aren't likely to become blocking?

I was actually wondering whether the right solution was to have a
 element (XEP-0297) containing a copy of the stanza - that
would then include from, to, id, etc, and we could stuff a delay in there
too, either inside the stanza or outside the forwarded inside the content.

Feels more reuse-y.


> 2.  In an encryption protocol idea that I briefly entertained, I was
> pondering about actually embedding a regular XMPP  stanza
> inside the encrypted container, with the from and to addresses being
> bare JIDs of the respective parties. This _might_ make the XML parsing /
> stanza reinjection part of things more straight-forward, but I'm not
> going to die on this hill.
>
>
I should totally read your entire message before replying to the first
section. :-)


>
> 3. From §9:
>
> > After verifying the integrity of the  element, the recipient
> > needs to make sure that no blacklisted elements are found within the
> > payload. Any forbidden elements MUST be dropped before the message is
> > processed any further.
>
> I would prefer aborting the processing altogether instead of dropping
> individual elements. In the context of security, a protocol is more
> robust if it properly rejects unexpected border cases.
>
>
As I noted, I don't think there's any harm in having (for example) hint
included inside the encryption. I cannot think of a single attack that
including additional encrypted data would usefully cause.

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

Re: [Standards] Proposed XMPP Extension: Stanza Content Encryption

[Dave Cridland]

On Mon, 24 Jun 2019 at 20:11, Paul Schaub  wrote:

> Am 24.06.19 um 19:04 schrieb Ненахов Андрей:
> > пн, 24 июн. 2019 г. в 21:59, Georg Lukas :
> >> 1. I'd like to see certain fields of the  being REQUIRED,
> >> especially:
> >>
> >> - the from address
> > So much for deniability.
> >
>
> Yeah, I'd rather keep it flexible and let the encryption XEP which
> defines a SCE profile decide, which fields to use and not to use. OX for
> instance should probably use the "full stack" of affix elements, while
> OTR would stay away from most of them (except maybe timestamp).
>
>
I would rather everything used the same.

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

Re: [Standards] Inbox and Other Stories

[Dave Cridland]

On Mon, 24 Jun 2019 at 20:43, Florian Schmaus  wrote:

> On 18.06.19 13:05, Dave Cridland wrote:
> > On Mon, 17 Jun 2019 at 17:09, Florian Schmaus  > <mailto:f...@geekplace.eu>> wrote:
> >
> > The solution back then was PEP, which is based on PubSub. Why would
> you
> > want to build a publish-subscribe mechanism not on XEP-0060 PubSub?
> >
> >
> > It's possible to put everything into XEP-0060 - indeed, XEP-0207
> > discusses exactly this, and shows examples of putting the roster and
> > presence notifications into PubSub.
>
> If XEP-0207 tries to deliver a message within a humorous XEP, then I am
> not sure which message that is. Of course no one would seriously want to
> base the Roster on PubSub/PEP at this stage. But if we where to
> completely design it from scratch in a clean room scenario, then using
> existing building blocks is always an option (and IMHO a desirable one).
>
>
I don't think you mean clean room, do you? In any case, it's not clear that
you'd use PEP to build a roster on (especially given that PEP depends on
the roster).

At best, you'd have to have a code-as-a-node PEP node for the roster.
That's achievable, but I suspect it's a bit of a pain in most servers.


> > I'm not going that route because the additional semantics of the roster
> > are useful here - but if you're open to replacing the roster entirely
> > with a more scalable design, I'm totally open to that.
>
> I am curious what additional semantics that are, besides the coupling of
> some data to a JID and roster pushes (which would probably do more harm
> than good).
>
>
The roster is a fundamental control structure within XMPP, and is also well
understood. The semantics that exist are that this is a list of contacts -
we tend to use it for contacts for which we have a presence subscription,
but note that the original design - still available - allows one to insert
any Jid at all into the roster manually. The subscription state is simply
some automatically tracked metadata. There is also other metadata (name,
groups) which is traditionally under the user's direct and exclusive
control (though in practise, not always).

As such, I think it's a natural place to consider adding more metadata.

You're quite right, of course, that we cannot simply force additional data
in without careful thought.


> > What about entries which are not in the roster?
> >
> >
> > Put them in, and mark them as ad-hoc entries.
>
> This could potentially cause UX issues for users with a lot of
> non-roster chats and clients unaware of the marker.
>
>
Not a problem.

Firstly, we understand how to do extensions etc. Secondly, even if we
didn't, the roster can contain arbitrary jids. At worst, this would be
additional clutter (and at best, it'd give users ephemeral entries in the
roster for ad-hoc chats).

> What about entities
> > which are not interested in the additional roster metadata?
> >
> >
> > This one is really easy - we really do know how to negotiate extensions
> > these days. If a client doesn't want to know, we'll just not tell it.
>
> And how does it affect roster versioning? Will there be two versions of
> the roster, one for the clients which did not request the additional
> metadata and one for the clients which did? Is there a roster push every
> time some metadata changes? If so, does it contain all the other metadata?
>
>

Lots of questions, so lots of answers:

a) For additional jids, it actually doesn't matter how it affects roster
versioning. If a client asks for version X of the roster without ad-hoc
entries, and there are subsequent changes which only affect the non-visible
roster entries, the client will see no difference. If a change happens to
move the roster version to Y, it'll just work.

b) Hence, probably not. But that said, servers can do so if they wish, I
don't think it matters.

c) Not for the metadata we've been discussing (unread, last message, etc)

d) Again, I don't think we include most metadata in the roster pushes.

This all said, I have to admit I think that outside some very specialist
cases, we shouldn't be worrying over roster versioning beyond the "no
change" case. Perhaps that view might change if we consider adding
substantially to the roster though.


> I do not believe that this is a desirable approach for the same reason I
> don't want MIX channels in the roster.
>
> Instead we should probably consider creating a generic way to retrieve
> (and store) arbitrary metadata linked to (bare) JIDs. That metadata
> could include unread count, which would be server generated. It could
> act as 'kind' marker for bare JIDs, marking e.g. MIX channels. And could
> also be used to store user-provided per-jid settings.
>
>
So

Re: [Standards] Proposed XMPP Extension: Stanza Content Encryption

[Dave Cridland]

On Wed, 19 Jun 2019 at 16:00, Jonas Schäfer  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Stanza Content Encryption
> Abstract:
> The Stanza Content Encryption (SCE) protocol is intended as a way to
> allow clients to securely exchange arbitrary extension elements using
> different end-to-end encryption schemes.
>
> URL: https://xmpp.org/extensions/inbox/xep-sce.html
>
>
This seems like a problem worth solving, and this seems like it's the right
first step.

I'd like to see, ultimately, every E2EE mechanism we have standardized on
using a single definition of what elements can be encrypted and what format
the encrypted message has, and this seems to be a good step along the path
toward providing such a definition.

Non-blocking comments follow (no need to address these before publication,
or, indeed, at all):

1) I'm a little thrown by the  element. It's an element which
has no actual definition of content beyond "Your encryption mechanism
decides what goes here". There's no definition of where it goes, either -
§6 implies it goes in place of the  element for OMEMO, but that's
about it. It feels to me as if each E2EE mechanism would have to define
this itself, and that raises the question of whether this element even
needs a definition in this document.

2) This document is very light on definitions - I think it's fairly obvious
what the elements are, but it doesn't go out of its way to eliminate the
guesswork.

3) I don't think the "decrypt" pathway is quite right. I think it's:

Pre) A client MUST have a policy on which elements must be encrypted, and
which MAY be encrypted. Clients need not consider if any elements MUST NOT
be encrypted during decrypt.

a) From the original stanza, remove any elements which are (by policy) set
to be always encrypted.

b) From the  element, copy any metadata to the stanza, marking as
encrypted. Where the metadata exists, a client MAY ignore (and discard) the
original, or MAY emit an error (for example, if the "to" or "from" address
mismatches, this might generate an error).

c) From the  element, copy any elements to the stanza (marking as
encrypted). Again, if the elements exist, a client MAY ignore (and discard)
the original, add the new one alongside, or generate an error. (An example
is that is a security label differs, a client MAY choose to trust its
server and use the original, ignore it and use the encrypted version, or
check to see if the different label is a valid transformation via
equivalent policy matching).

This differed from your suggestion because a hint really doesn't matter if
it *is* encrypted as well - it's just useless to the server there. But if
another metadata element were present unencrypted *and* encrypted, it might
be rather important - as the security label example shows. Equally, things
like  get added by intermediaries, and those are fine except for
any delay stamp from the originating client.

This also means that §8 is only for encryption, probably isn't a
"blacklist" as such, and is probably OK being a rule of thumb.

In any case, these all feel like things we can sort out when it has a
number.

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

Re: [Standards] XEP-0191 leads to stale presence?

[Dave Cridland]

On Sat, 22 Jun 2019 at 19:12, Dave Cridland  wrote:

>
>
> On Thu, 20 Jun 2019 at 20:32, Kim Alvefur  wrote:
>
>> Hi,
>>
>> While working on a fix for Prosodys XEP-0191 implementation¹ regarding
>> presence sent to a blocked JID to pretend that the blocking user is
>> offline, and then re-send presence again if they unblock.
>>
>> However, since if you block someone, your view of their presence will
>> become stale. The XEP does not say anything about this. Is it implied
>> that the server should send a presence probe or otherwise try to do
>> something about that?
>>
>>
> Yes.
>
>

More usefully:

I always assumed the intent of XEP-0191 was to make the subject appear
offline to any blocked contacts, and make any blocked contacts appear
offline, for the duration of the block.

So as I recall - and no doubt Edwin and Kev can say if I recall correctly -
when I last implemented it from scratch, I had the server probe a contact
when unblocked, and and otherwise make it appear as if both sides had just
come online (or stayed offline, or whatever).

But you're quite right, none of this is in the letter of the specification
(even the intent).

Dave.


>
>> ¹ https://issues.prosody.im/1380
>>
>> --
>> Regards,
>> Kim "Zash" Alvefur
>> ___
>> 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-0191 leads to stale presence?

[Dave Cridland]

On Thu, 20 Jun 2019 at 20:32, Kim Alvefur  wrote:

> Hi,
>
> While working on a fix for Prosodys XEP-0191 implementation¹ regarding
> presence sent to a blocked JID to pretend that the blocking user is
> offline, and then re-send presence again if they unblock.
>
> However, since if you block someone, your view of their presence will
> become stale. The XEP does not say anything about this. Is it implied
> that the server should send a presence probe or otherwise try to do
> something about that?
>
>
Yes.


>
> ¹ https://issues.prosody.im/1380
>
> --
> Regards,
> Kim "Zash" Alvefur
> ___
> 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] Inbox and Other Stories

[Dave Cridland]

On Mon, 17 Jun 2019 at 17:09, Florian Schmaus  wrote:

> The solution back then was PEP, which is based on PubSub. Why would you
> want to build a publish-subscribe mechanism not on XEP-0060 PubSub?
>
>
It's possible to put everything into XEP-0060 - indeed, XEP-0207 discusses
exactly this, and shows examples of putting the roster and presence
notifications into PubSub.

I'm not going that route because the additional semantics of the roster are
useful here - but if you're open to replacing the roster entirely with a
more scalable design, I'm totally open to that.


> What about entries which are not in the roster?


Put them in, and mark them as ad-hoc entries.


> What about entities
> which are not interested in the additional roster metadata?
>

This one is really easy - we really do know how to negotiate extensions
these days. If a client doesn't want to know, we'll just not tell it.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XMPP Council Agenda 2019-06-12

[Dave Cridland]

The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests and issues marked "Needs Council":
https://github.com/xsf/xeps/labels/Needs%20Council
* Random mails from Standards List
* Random suggestions directly to me
* A discussion in council@ the day before where Jonas and I frantically try
to collate everything.
* Things sent in reply to this message because, let's face it, things get
forgotten.

I (try to) send out the final agenda about 24 hours in advance.

Agenda as follows:
1) Roll Call

2) Agenda Bashing

* Feel free to pre-bash if you think something's missing.

3) Items for voting:

a) Last Call: XEP-0280 (Message Carbons)

Dave has offered to shepherd this one through.

b) Last Call: XEP-0300 (Crypto hashes)

Jonas has offered to shepherd this one through if needs be.

4) Outstanding Votes

(None?)

5) Next Meeting

6) AOB

7) Close

Note that I'm aiming for 30 minutes.

Meetings are normally held every Wednesday at 1500 UTC in the
xmpp:coun...@muc.xmpp.org?join
 chatroom.
Meetings are open, and anyone
(XSF Member or not) may attend, though only XMPP Council members may
vote. Relevant comments from the floor are welcomed.

Thanks,

Dave.
(As Council Chair).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Whitespace "ping"

[Dave Cridland]

I think the optimal ping, from the server's perspective, radically changes
depending on whether there are outstanding messages, and whether there's an
outstanding XEP-0198 ack.

>From a client's perspective it's really dependent on whether the user is
active, and if not, whether there is a push notification scheme in play.

For the server, I think the ideal algorithm is roughly:

a) If the server spoke last, and there is no XEP-0198 in play, then use a
XEP-0199 ping after N (where N is in the order of 30 seconds). A successful
ping means the client has now spoken last, of course.
b) If the server spoke last and there is XEP-0198 in play, then request an
acknowledgement after M (where M is anything from 0 to about 5 seconds)
after sending a stanza.
c) If the client spoke last, send a ping (XEP-0199 or XEP-0198 ) after
P seconds (where P is in the order of 300). This is purely to clean up old
sessions.

For the client:

a) If the user is active, ping every 2 minutes (perhaps).
b) Otherwise, if there is no push, ping every 5 minutes.
c) Otherwise, don't ping at all.

Dave.

On Tue, 11 Jun 2019 at 13:31, Guus der Kinderen 
wrote:

> I'd have to check, but I think we're sending a IQ Ping when the client
> misses it's first white space ping interval (whatever we deem is
> appropriate in that server config), and define the client to be
> disconnected when it doesn't respond in a timely manner. This covers both
> of your "the client is being silly" scenario's: to many whitespace pings
> aren't adding much overhead to the server, while to few pings are covered
> by the IQ Ping. I agree with you that it's all very unspecified, which
> could be improved on. I'm not seeing much of a direct  _need_ to do that,
> but I'd not oppose it either.
>
> On Tue, 11 Jun 2019 at 14:24, Mickaël Rémond 
> wrote:
>
>> Hello Guus,
>>
>> On 11 Jun 2019, at 14:00, Guus der Kinderen 
>> wrote:
>>
>> What we need basically is a way to negotiate the interval with server
>>
>>
>> I'm not sure if this is _needed_? Without this being a requirement, much
>> of the complexity of "making this more standard" falls away.
>>
>>
>> Well, I think if the server does not have to approve the value, client
>> could expect to set it to something extreme (like 1s) or useless (like 1
>> days). The server could thus reply with a different value. And still the
>> server needs to know at which rate the client is expected to send the keep
>> alive.
>> But, yes, it is always possible to do something like that in a non
>> standard way. My point was trying to agree on something to make life of
>> client developers easier :)
>>
>> A server could, before determining that a connection is lost, attempt to
>> send any IQ stanza (PING is an obvious choice, but any query will do). As
>> the client is obliged to respond, if anything with an error, the server
>> knows if the connection is, in fact, lost.
>>
>>
>> What would be the trigger for determining that the connection is lost and
>> send the ping? Is it whitespace keep-alive or anything else?
>>
>> Thanks!
>>
>> --
>> Mickaël Rémond
>>
>> ___
>> 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
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Inbox and Other Stories

[Dave Cridland]

On Wed, 29 May 2019 at 12:27, Ненахов Андрей 
wrote:

> We have this (not exactly this, but for the very same purpose) mostly
> implemented and already working, would be happy to share the results with
> everyone. Currently, it's implemented on a server, client support (in Web
> version of Xabber) will arrive in a week or two. We also plan to release an
> open-source server (ejabberd fork) that will support this.
>
> Problem is, we definitely lack skills putting this as a 'XEP' formatted
> thing with proper description, and, what's worse, current documentation is
> mostly in Russian, but XMLs are in english and if someone would volunteer
> help us putting it in a XEP-like way, I'll muster myself to translate
> crucial bits into English.
>
>
Right - I knew you had this but had forgotten. It'd be great to collate all
these ideas and pick the best bits from them all.

Just a high-level technical sketch would be really useful.


> ср, 29 мая 2019 г. в 16:12, Dave Cridland :
>
>> Having spent a while playing with - gasp! - non-XMPP based chat systems,
>> I'm quite taken with the notion that some kind of Inbox might be rather
>> useful to us.
>>
>> Currently, there is Erlang Solutions (ESL)'s Inbox, which is essentially
>> a duplication of MAM with some chat state tracking. It's more than just
>> that, of course, but the essential concept I see is that it's a different,
>> but largely equivalent interface to MAM, with the concept of an unread
>> counter added.
>>
>> Instagram, on the other hand, has no roster, as such, and its Inbox
>> simply lists (recent) conversations, in much the same way as a client might
>> display them. Each record contains the conversation's participants, and the
>> most recent message. Things like presence subscription, in the Instagram
>> model, are simply the open conversations.
>>
>> We do have a roster, of course, and we're putting more things into it -
>> MIX channels, MUC Light in ESL's case, and so on.
>>
>> This makes me wonder if the right way to design an Inbox is actually to
>> enhance our Roster with MAM and state awareness, and make it the
>> conversation information hub for IM.
>>
>> Let's suppose that the nature of what is "unread" is equivalent across
>> all clients of a particular user, to begin with.
>>
>> If a client requests the inbox "since" a particular point, it would then
>> receive a series of records:
>>
>> First, a set of N records similar to a roster item, containing a jid,
>> subscription state, the last archive-id received in the conversation, and
>> the number of unacknowledged (by some definition) messages. Our roster also
>> includes groups and a name; we could also include the type (MUC, MIX, or a
>> user), the full message, etc - these are all optimisations.
>>
>> We do not, actually, need the numbers of unread messages - a client
>> seeing that the last archive-id isn't in its cache knows the conversation
>> has messages that are unread to it, at least. But if we can track message
>> read state, that's useful for multi-device.
>>
>> Finally, an update message to indicate the current point, where things
>> change. I would use an archive-id again here - even if the thing causing
>> the update isn't an archived message at all. This allows a client to ask
>> for the archive either since a particular message, or since an event.
>>
>> You'll note I'm not building this directly on PubSub in the XEP-0060 (or
>> XEP-0163) sense - instead I'm proposing building this on the existing
>> Roster and MAM.
>>
>> So:
>>
>> 
>>   
>> 
>>   
>>   
>> 
>>
>> 
>>
>> I'd dearly love to return updates using , MAM-style, actually.
>> But let's say we stick with the roster design, the pushes look like:
>>
>> > type='set'>
>>  
>>
>>   
>>   
>>   
>>Yeah, sure - whenever you like.
>>   
>>  
>>
>>
>> Any message "counts" for updating the roster version, by dint of unifying
>> the namespace of stanza-id (for archive) and roster version. So any new
>> message arriving updates the current point of the roster as well, and any
>> new change in the roster changes the archive pointer similarly.
>>
>> Updating the shared unread count could be by Carbonizing the
>> read-receipts (or similar), and using the stanza-id from that, or by an
>> explicit roster push. Either's good - I think the roster pushes are more
>> explicit, 

[Standards] No Council Meeting Today

[Dave Cridland]

Hi all,

There would normally be an XMPP Council meeting today (Wednesday) at 1500
UTC, but there's nothing on the agenda, so we've decided to skip this week.
Expect a suitably witty set of non-minutes from Tedd Sterr.

The agenda is collated from (in order of reliability):
* Github pull requests and issues marked "Needs Council":
https://github.com/xsf/xeps/labels/Needs%20Council
* Random mails from Standards List
* Random suggestions directly to me
* A discussion in council@ the day before where Jonas and I frantically try
to collate everything.
* Things sent in reply to the agenda because, let's face it, things get
forgotten.

I (try to) send out the final agenda about 24 hours in advance.

Meetings are normally held every Wednesday at 1500 UTC in the
xmpp:coun...@muc.xmpp.org?join
 chatroom.
Meetings are open, and anyone
(XSF Member or not) may attend, though only XMPP Council members may
vote. Relevant comments from the floor are welcomed.

Thanks all,

Dave. (As Council Chair)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Inbox and Other Stories

[Dave Cridland]

Having spent a while playing with - gasp! - non-XMPP based chat systems,
I'm quite taken with the notion that some kind of Inbox might be rather
useful to us.

Currently, there is Erlang Solutions (ESL)'s Inbox, which is essentially a
duplication of MAM with some chat state tracking. It's more than just that,
of course, but the essential concept I see is that it's a different, but
largely equivalent interface to MAM, with the concept of an unread counter
added.

Instagram, on the other hand, has no roster, as such, and its Inbox simply
lists (recent) conversations, in much the same way as a client might
display them. Each record contains the conversation's participants, and the
most recent message. Things like presence subscription, in the Instagram
model, are simply the open conversations.

We do have a roster, of course, and we're putting more things into it - MIX
channels, MUC Light in ESL's case, and so on.

This makes me wonder if the right way to design an Inbox is actually to
enhance our Roster with MAM and state awareness, and make it the
conversation information hub for IM.

Let's suppose that the nature of what is "unread" is equivalent across all
clients of a particular user, to begin with.

If a client requests the inbox "since" a particular point, it would then
receive a series of records:

First, a set of N records similar to a roster item, containing a jid,
subscription state, the last archive-id received in the conversation, and
the number of unacknowledged (by some definition) messages. Our roster also
includes groups and a name; we could also include the type (MUC, MIX, or a
user), the full message, etc - these are all optimisations.

We do not, actually, need the numbers of unread messages - a client seeing
that the last archive-id isn't in its cache knows the conversation has
messages that are unread to it, at least. But if we can track message read
state, that's useful for multi-device.

Finally, an update message to indicate the current point, where things
change. I would use an archive-id again here - even if the thing causing
the update isn't an archived message at all. This allows a client to ask
for the archive either since a particular message, or since an event.

You'll note I'm not building this directly on PubSub in the XEP-0060 (or
XEP-0163) sense - instead I'm proposing building this on the existing
Roster and MAM.

So:


  

  
  

   


I'd dearly love to return updates using , MAM-style, actually.
But let's say we stick with the roster design, the pushes look like:


 
   
  
  
  
   Yeah, sure - whenever you like.
  
 
   

Any message "counts" for updating the roster version, by dint of unifying
the namespace of stanza-id (for archive) and roster version. So any new
message arriving updates the current point of the roster as well, and any
new change in the roster changes the archive pointer similarly.

Updating the shared unread count could be by Carbonizing the read-receipts
(or similar), and using the stanza-id from that, or by an explicit roster
push. Either's good - I think the roster pushes are more explicit, which is
helpful.

I'm fully expecting some push-back here. Comments are, of course, welcome.

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

[Standards] XMPP Council Agenda 2019-05-22

[Dave Cridland]

The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests and issues marked "Needs Council":
https://github.com/xsf/xeps/labels/Needs%20Council
* Random mails from Standards List
* Random suggestions directly to me
* A discussion in council@ the day before where Jonas and I frantically try
to collate everything.
* Things sent in reply to this message because, let's face it, things get
forgotten.

I (try to) send out the final agenda about 24 hours in advance.

Agenda as follows:
1) Roll Call

2) Agenda Bashing

* Feel free to pre-bash if you think something's missing.

3) Items for voting:

a) https://github.com/xsf/xeps/pull/690

XEP-0184: Make the schema require @id in 

Old and reopened PR, Council's original concerns may have been addressed.

b) https://github.com/xsf/xeps/pull/750

XEP-0300: remove content which has been moved to XEP-0414

This is Experimental, however the authors appear unresponsive and Jonas
would like to merge this and Last Call it.

4) Outstanding Votes

(Another one for Tedd Sterr's NPE joke this time around - let's please keep
it this way)

5) Next Meeting

6) AOB

7) Close

Note that I'm aiming for 30 minutes.

Meetings are normally held every Wednesday at 1500 UTC in the
xmpp:coun...@muc.xmpp.org?join
 chatroom.
Meetings are open, and anyone
(XSF Member or not) may attend, though only XMPP Council members may
vote. Relevant comments from the floor are welcomed.

Thanks,

Dave.
(As Council Chair).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Stanza Content Encryption

[Dave Cridland]

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 list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [Council] XMPP Council Agenda 2019-04-17

[Dave Cridland]

Also, I think we can squeeze on

X) https://github.com/xsf/xeps/pull/785 -

XEP-0260: Replace broken link with archive.org

I'm not sure if it's really more than Editorial given the nature of it, but
we may as well quickly discuss since it won't delay.

On Wed, 17 Apr 2019 at 09:23, Dave Cridland  wrote:

> Consider it on this week's agenda.
>
> On Wed, 17 Apr 2019 at 06:39, Georg Lukas  wrote:
>
>> * Dave Cridland  [2019-04-16 18:21]:
>> > a) https://github.com/xsf/xeps/pull/736
>> >
>> > XEP-0308: Allow message correction in MUC
>>
>> While we are at it, I'd like to also add:
>>
>> aa) XEP-0308: relax from-full-JID requirement
>>
>> https://github.com/xsf/xeps/pull/784
>>
>> Thanks very much,
>>
>>
>> Georg
>>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [Council] XMPP Council Agenda 2019-04-17

[Dave Cridland]

Consider it on this week's agenda.

On Wed, 17 Apr 2019 at 06:39, Georg Lukas  wrote:

> * Dave Cridland  [2019-04-16 18:21]:
> > a) https://github.com/xsf/xeps/pull/736
> >
> > XEP-0308: Allow message correction in MUC
>
> While we are at it, I'd like to also add:
>
> aa) XEP-0308: relax from-full-JID requirement
>
> https://github.com/xsf/xeps/pull/784
>
> Thanks very much,
>
>
> Georg
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XMPP Council Agenda 2019-04-17

[Dave Cridland]

The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests and issues marked "Needs Council":
https://github.com/xsf/xeps/labels/Needs%20Council
* Random mails from Standards List
* Random suggestions directly to me

I (try to) send out the final agenda about 24 hours in advance.

Agenda as follows:
1) Roll Call

2) Agenda Bashing

* Feel free to pre-bash if you think something's missing.

3) Items for voting:

a) https://github.com/xsf/xeps/pull/736

XEP-0308: Allow message correction in MUC

b) Discussion: https://github.com/xsf/xeps/pull/778

XEP-0280: Rewrite of the 'Messages Eligible for Carbons Delivery' section

Georg asked us to discuss a way to make progress here.

4) Outstanding Votes

5) Next Meeting

6) AOB

7) Close

Note that I'm aiming for 30 minutes.

Meetings are normally held every Wednesday at 1500 UTC in the
xmpp:coun...@muc.xmpp.org?join
 chatroom.
Meetings are open, and anyone
(XSF Member or not) may attend, though only XMPP Council members may
vote. Relevant comments from the floor are welcomed.

Thanks,

Dave.
(As Council Chair).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-04-14

[Dave Cridland]

On Sun, 14 Apr 2019 at 19:44, Tedd Sterr  wrote:

> *2019-03-20 (expired 2019-04-03)*
> PASSED (-0:0:+5) *Last Call: XEP-0353 (Jingle Message Initiation)* -
> https://xmpp.org/extensions/xep-0353.html
>
>
> *2019-03-27 (expired 2019-04-10)*
>
> PASSED (-0:2:+3)
> *Advance to Draft: XEP-0412 (XMPP Compliance Suites 2019)* -
> https://xmpp.org/extensions/xep-0412.html
> Dave: +0 (in two minds whether we should have a Compliance Suite if the
> community is disinterested)
> Georg: +1
> Jonas: +1
> Kev: -0 (our current annual Compliance Suites is unhelpful, and costs lots
> of noise and time, but I won't block progress)
> Link: +1
>
> VETOED (-2:3:0)
> *Proposed XMPP Extension: Automatic Trust Transfer (ATT)* -
> https://xmpp.org/extensions/inbox/automatic-trust-transfer.html
> Dave: -1 (don't think there's evidence of this being anything beyond a
> very high-level sketch; not convinced we have the expertise to adequately
> design a cryptographic trust system)
> Georg: [abstained]
> Jonas: [abstained]
> Kev: -1 (don't think it's possible to implement from the spec as-is, but
> more crucially there are fundamental security considerations
> missing/non-obvious; publishing this right now would be ill-advised)
> Link: [abstained]
>
> PASSED (-0:2:+3)
> *PR #764 - XEP-0308: Clarify correcting a message multiple times* -
> https://github.com/xsf/xeps/pull/764
> Dave: +0 (pretty sure further clarifications are warranted, and it's nice
> to have a single way of doing things - this even looks like the right way -
> but not clear it makes any difference either way; would rather see some
> suggestion that clients SHOULD treat a corrected correction as a correction
> of the original message)
> Georg: -0 (as long as there is wording that excludes MAM IDs and receipts
> from the "all child elements" initial rationale)
> Jonas: +1
> Kev: +1 (more logical or not, this clarification follows from the existing
> text - correction affects a message's payloads, not its identity; not a
> change of behaviour, so largely Editorial)
> Link: +1 (once we reach the MAM companion table, every correction does
> indeed pertain to the original message)
>
>
> *2019-04-10 (expiring 2019-04-24)*
>
> *PR #781 - XEP-0308: Correct contents only* -
> https://github.com/xsf/xeps/pull/781
> Dave: [pending]
> Georg: +0 (for the sake of not dying on hills)
> Jonas: +1 (the text makes things clearer)
> Kev: +1
> Link: +1
>
>
+1


> *PR #779 - XEP-0184: add a box about types and JIDs* -
> https://github.com/xsf/xeps/pull/779
> Dave: [pending]
> Georg: +1
> Jonas: +1
> Kev: [on-list]
> Link: +1
>

+1


>
> ___
> 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-0418 (DNS Queries over XMPP (DoX))

[Dave Cridland]

On Thu, 4 Apr 2019 at 17:26, Peter Saint-Andre  wrote:

> On 4/1/19 12:59 PM, Florian Schmaus wrote:
> > On 30.03.19 16:48, Jonas Schäfer (XSF Editor) wrote:
> >> Version 0.1.0 of XEP-0418 (DNS Queries over XMPP (DoX)) has been
> >> released.
> >>
> >> Abstract:
> >> This specification defines an XMPP protocol extension for sending DNS
> >> queries and getting DNS responses over XML streams. Each DNS query-
> >> response pair is mapped into an IQ exchange.
> >>
> >> Changelog:
> >> Accepted by vote of Council on 2019-03-13. (XEP Editor (jsc))
> >>
> >> URL: https://xmpp.org/extensions/xep-0418.html
> >
> > Love it. Although I don't have an immediate use case, I could imagine
> > that one will come up possibly.
>
> It's been noted on the DNSOP list:
>
> https://mailarchive.ietf.org/arch/msg/dnsop/hbRHqdvQZquBtNx3IVede9VMSE8
>
> In general I'm not a fan of working on things that "don't have an
> immediate use case". Are folks here actively interested in implementing
> and deploying DoX or is it just a thought experiment so far?
>
>
Yes, people have actually implemented and deployed it.


> Peter
>
> ___
> 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] Council Voting Summary 2019-03-31

[Dave Cridland]

On Wed, 3 Apr 2019 at 17:17, Paul Schaub  wrote:

> That's what I was going to say. There is no new crypto, and no cross
> signing, just exchanging fingerprints over an already secured channel. If
> that would be considered inventing you own crypto, we wouldn't be
> exchanging any encrypted messages at all.
>
>
There's no new algorithms, but this is a new automated trust system with
non-transitive properties. That's applied cryptography at least to the
level of, say, POSH, or similar. OMEMO just lifts libsignal and ports it to
XMPP with no changes in the "How". EAX, similarly, just applies X.509 in
fairly normal ways to XMPP. But we ran POSH through the IETF because it
built a different trust chain mechanism onto X.509. Why wouldn't we with
this?

The *people* involved might well have enough capability to review this
document, but I wouldn't claim to, and with the best will in the world, I
don't think either the XSF as a whole or the XMPP Council has the
institutional capability to review such a thing either - even if it were
complete enough to be able to fully understand its security, which it is
not.

Finally, there *is* cross-signing in all but name - the ATT message is
inherently signed when sent over the OMEMO channel. Yes, it's signing an
ATT message containing a fingerprint, rather than signing the public key
info of the key directly, but unless I'm missing something, this is
fundamentally equivalent. Yes, the signature is ephemeral, but it is a
signature nonetheless.


> Am 3. April 2019 18:12:47 MESZ schrieb "W. Martin Borgert" <
> deba...@debian.org>:
>>
>> Quoting Dave Cridland :
>>
>>> * But this is creating our own cryptography, and the XSF should not be
>>> doing that.
>>>
>>
>> If I understand ATT correctly, it's not cryptography in itself, but
>> automation of key "trust state" copying. More a kind of convenience
>> function. Please CMIIW.
>> --
>> 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
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-03-31

[Dave Cridland]

On Wed, 3 Apr 2019 at 15:34, Melvin Keskin  wrote:

> You wrote in your first message on ATT:
> > This alone is absolutely not a blocker to adoption in my view.
>
> Then I read:
> > -1 - I don't think there's evidence of this being anything beyond a
> > very
> > high-level sketch. Designing a cryptographic trust system is complex,
> > and
> > I'm not convinced we have the expertise to adequately do such a
> > thing.
>
> I am confused now because I thought you would accept ATT but it needs
> more improvement. What did you mean by "This alone is absolutely not a
> blocker to adoption in my view."?
>

I said, roughly:

* This specification is just a high-level sketch.
* But this is creating our own cryptography, and the XSF should not be
doing that.

The first is not a blocker. The second, I think, is.

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

Re: [Standards] Council Voting Summary 2019-03-31

[Dave Cridland]

On Sun, 31 Mar 2019 at 21:47, Tedd Sterr  wrote:

> *2019-03-13 (expired 2019-03-27)*
>
> PASSED (-0:2:+3)
> *Proposed XMPP Extension: E2E Authentication in XMPP: Certificate Issuance
> and Revocation* - https://xmpp.org/extensions/inbox/eax-cir.html
> Dave: +1 (tentatively; seems in-scope)
> Georg: +1 (have some minor detail issues with this, but nothing critical)
> Jonas: +1
> Kev: [abstained]
> Link: [abstained]
>
> PASSED (-0:2:+3)
> *Proposed XMPP Extension: DNS Queries over XMPP (DoX)* -
> https://xmpp.org/extensions/inbox/dox.html
> Dave: +1 (will be pushing hard for Security Considerations in place about
> privacy)
> Georg: +1 (another potential use-case: XMPP clients behind an HTTP/socks
> proxy (resolving SRV would leak DNS data); a section about service
> discovery before connecting to XMPP would be great)
> Jonas: -0 (my personal distaste for weird things like DoH shouldn't stand
> in the way, and this is just as sensible)
> Kev: [abstained]
> Link: +1 (because it's a valid usecase and seems properly written)
>
>
> *2019-03-20 (expiring 2019-04-03)*
>
> *Last Call: XEP-0353 (Jingle Message Initiation)* -
> https://xmpp.org/extensions/xep-0353.html
> Dave: +1
> Georg: +1
> Jonas: +1
> Kev: [pending]
> Link: +1
>
>
> *2019-03-27 (expiring 2019-04-10)*
>
> *Advance to Draft: XEP-0412 (XMPP Compliance Suites 2019)* -
> https://xmpp.org/extensions/xep-0412.html
> Dave: [on-list] (wonder if we should consider a last call once more given
> the change of author)
> Georg: +1
> Jonas: +1
> Kev: [pending]
> Link: +1
>
>
+0 - I'm in two minds as to whether we should have a Compliance Suite if
there's no interest in the contents from the community, but equally it does
little harm. (I hope).


> *Proposed XMPP Extension: Automatic Trust Transfer (ATT)* -
> https://xmpp.org/extensions/inbox/automatic-trust-transfer.html
> Dave: [on-list]
> Georg: [on-list]
> Jonas: [on-list]
> Kev: [pending]
> Link: [on-list]
>
>
-1 - I don't think there's evidence of this being anything beyond a very
high-level sketch. Designing a cryptographic trust system is complex, and
I'm not convinced we have the expertise to adequately do such a thing.


> *PR #764 - XEP-0308: Clarify correcting a message multiple times* -
> https://github.com/xsf/xeps/pull/764
> Dave: [on-list]
> Georg: -1 (the XEP is in dire need of clarification, but it's more logical
> to correct the last message, not the first, e.g. when fetching partial MUC
> history)
> Jonas: +1
> Kev: [pending]
> Link: 0 (will break clients, but so will the other way, even if that seems
> more logical to me)
>
>
+0 - I'm pretty sure there are further clarifications on the nature and
scope of corrections, and it's nice to have a single way of doing things,
and this even looks like the right way, but it's not clear it makes any
difference either way - so I'd rather see some suggestion that if a
correction is corrected clients SHOULD treat this as a correction of the
original message.


> ___
> 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] Stanza Content Encryption

[Dave Cridland]

Why is the IEEE working on this? Surely it would be considerably more
productive just to ask the XSF (or even the IETF, I can see arguments for
both) about the problem?

On Mon, 1 Apr 2019 at 10:51, Peter Waher  wrote:

> Hello Paul, and those in the community interested in end-to-end encryption
> of stanzas.
>
>
>
> Within the IEEE IoT Harmonization effort, there is a mechanism to
> E2E-encrypt stanzas in XMPP:
>
> https://gitlab.com/IEEE-SA/XMPPI/IoT/blob/master/E2E.md
>
>
>
> Site for the IEEE IoT Harmonization project:
>
> https://gitlab.com/IEEE-SA/XMPPI/IoT
>
>
>
> Best regards,
>
> Peter Waher
>
>
>
> --
>
> > Hi everyone!
> >
> > The Sprint in Berlin was great and it was huge fun meeting so many
> > developers (and users as well!) in person. There was a ton of
> > interesting discussions around OMEMO and other stuff, as well as some
> > productive coding (and Mate!).
> >
> > I took the opportunity to once again start a discussion around partial
> > stanza encryption. The results have been collected in the XMPP wiki:
> >
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.xmpp.org%2Fweb%2FStanza_encryptiondata=02%>
>
> 7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310sdata=YqVBLurjKA1xIqjIMqKweWXhm6hhk%2F7cdLfpwkiyOjg%3Dreserved=0
> 
> >
> > The ultimate goal is to create a ProtoXEP along with some experimental
> > implementations, so we can finally start to gather some experience on
> > this unexplored topic. I know there be dragons and we should carefully
> > think about rules to prevent evil things from happening, but we also
> > have to get started, as I think this topic has been postponed for all
> > too long.
> >
> > The specification is worked on on Github and a rendered version can be
> > found below (this is all what I came up with while on my train home).
> > The purpose of this mail is to get some first feedback and make people
> > aware about the work, so they can get involved in the process :)
> >
> >
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvanitasvitae%2Fflowdalic-xeps%2Ftree%2Fscedata=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310sdata=T61uPbN2631En4SqdiDMW2Gwk5pfgrCxZXFmFxHpt%2Bg%3Dreserved=0
>
> https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgeekplace.eu%2Fxeps%2Fxep-sce%2Fxep-sce.htmldata=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065422005321sdata=3BvePHpJPZICLrqxlfiRW7sCL0EwLRov%2FEc6l5i%2Bkic%3Dreserved=0
> >
> > I also created a small MUC on the topic, although the address is not
> > final, as I may move the conversation to a more stable server (mine is
> > hosted behind dyndns, so Schroedingers Chat might kick in :/).
> >
> > xmpp:s...@conference.jabberhead.tk?join
> >
> > Happy Hacking!
>
> ___
> 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] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Dave Cridland]

On Sat, 30 Mar 2019 at 10:16, Daniel Gultsch  wrote:

> Hi,
>
> I apologize in advanced for reiterating something that might have been
> obvious to anyone else but wasn’t to me:
>
> This XEP does two things:
> 1) Provide something that is basically equivalent to cross signing.
> Meaning if you trust one of my devices you can trust all of my devices
> 2) When on boarding a new device transfer the list of verified
> (authenticated) contacts to that new device.
>
>
This wasn't obvious to me either - also, I wasn't clear whether it was
sending verified contacts to verified contacts (ie, a sort of WoT). I got
there eventually via the examples, but I agree that spelling out the
objectives simply would help.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Dave Cridland]

On Fri, 29 Mar 2019 at 14:02, Evgeny  wrote:

>
>
> On Fri, Mar 29, 2019 at 4:57 PM, Dave Cridland 
> wrote:
> >
> > That's interesting, because my understanding was that the result of
> > ATT was that if I manually verify one of your keys, I could then
> > transitively trust all of your keys - I didn't read this as being
> > that I might trust any third party keys.
>
> Yes, I already corrected myself in the previous mail, sorry for
> confusion.
>
> > Indeed, I consider this to be essentially a channel binding problem
> > where we implicitly trust the "in person" channel - I think Winfried
> > might have a story to tell on why that can be a fallacious assumption.
>
> What exactly is a fallacious assumption?
>
>
Sorry, too much English. "Fallacious" simply means "based on mistaken
beliefs", or simply "wrong". We cannot always trust the "in-person" channel.

In Winfried's case, he attended the 2016 FOSDEM key signing event where
someone turned up with a specimen passport, and all but 20 people signed
his key anyway since they naturally assumed that nobody would be doing
that. Winfried was quite upset at the time, which is understandable, but I
still can't stop laughing.


> > I think you can (somewhat) combine them in the way that MLS does,
> > where each person has an identity key which signs each device key,
> > and that identity key can then be manually, WoT, or CA verified as
> > the users desire.
>
> I'm simply not competent enough to resolve this, I'm working on CA
> protocol in my XEP.
>

Nor am I - it requires proper cryptographers, who are working on these
problems at the IETF anyway.


>
> ___
> 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] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Dave Cridland]

On Fri, 29 Mar 2019 at 13:08, Evgeny  wrote:

> On Thu, Mar 28, 2019 at 8:23 PM, Dave Cridland 
> wrote:
> > Overall, my view is that this specification is very unclear and
> > impossible to implement as written.
>
> I don't understand how this will work in practice indeed.
> 1) The "trusted" graph is not connected (i.e. you cannot reach any
> vertex from any other vertex), thus, in the worst case the complexity
> of verification will remain the same. This is especially doubtful,
> since it's speculated that the topology of a social graph has power-law
> distribution [1] and thus only a few people will benefit from the
> "trust transfer".
>

That's interesting, because my understanding was that the result of ATT was
that if I manually verify one of your keys, I could then transitively trust
all of your keys - I didn't read this as being that I might trust any third
party keys.


> 2) The problem of manual verification is still unresolved, because for
> online persons (i.e. without meeting them offline) you have to use an
> already trusted channel to perform verification, so chicken and egg
> problem.
>

Indeed, I consider this to be essentially a channel binding problem where
we implicitly trust the "in person" channel - I think Winfried might have a
story to tell on why that can be a fallacious assumption.


> 3) Isn't it better to work on the problem together, i.e. in the context
> of my EAX proposals? If you don't trust the CA or want to have
> additional guarantees you can resort to manual or ATT verification. I
> don't see any contradictions here. Both approaches are kinda
> complementary and can be working together, unless you're reluctant and
> hate CAs.
>
>
I think you can (somewhat) combine them in the way that MLS does, where
each person has an identity key which signs each device key, and that
identity key can then be manually, WoT, or CA verified as the users desire.

But then, I'd also argue we should just wait for some real cryptographers
to give us MLS.


> [1] https://en.wikipedia.org/wiki/Scale-free_network#Examples
>
> ___
> 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] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Dave Cridland]

On Tue, 26 Mar 2019 at 16:44, Jonas Schäfer  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Automatic Trust Transfer (ATT)
> Abstract:
> ATT specifies an automatic transfer of trust in public identity keys
> used by the end-to-end encryption protocol OMEMO.
>
> URL: https://xmpp.org/extensions/inbox/automatic-trust-transfer.html


Several things about this have me concerned:

* It always worries me when people suggest security protocols and use odd
naming conventions. There is, surely, no such thing as "trust transfer",
whether automatic or not. Trust can be transitive, of course, but not
transferable.

* The messages are simply defined as being URIs. One assumes these are
transferred over XMPP, but it's not described how. Presumably these would
need to be authenticated messages somehow - are these intended to be
encrypted themselves using OMEMO? What format is used?

* §4.1 is virtually impossible to follow because there's no indication of
who owns what devices.

 * In §6, we see that Bob's trust of the keys A2 and A3 is predicated on a
continuing trust of the key A1, but the trust is described as absolute
rather than as a chain. If A1's key is later revoked, it is unclear whether
one expects B1 to continue to trust A2 and A3.

* It is not explained how A1 trusts A2 and A3, or vice-versa.

* §8.1 describes mandated behaviour, but does not explain what the attack
is nor how this behaviour mitigates the attack.

* §8.2 describes a general attack briefly, and then mandates behaviour.
Neither of which to my eyes has little or nothing to do with ATT itself,
but relates to OMEMO (or even XMPP) in general.

Overall, my view is that this specification is very unclear and impossible
to implement as written. This alone is absolutely not a blocker to adoption
in my view. However it is not clear whether the community has the ability
and expertise to adequately review and develop such a specification.

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

Re: [Standards] One true final way to mark up messages

[Dave Cridland]

Evgeny,

While I'm certain that Carlo is thick-skinned enough to ignore this remark,
I don't think it's helpful either to this thread or the community as a
whole. I appreciate it's hard not to react, I've done so myself many times
in the past, but I've learnt painfully that it is more useful to keep
things polite, technical and focused. Hopefully I manage to do this most of
the time. Feel free to call me out when I err, I do appreciate it - at
least in the long term. :-)

Please, everyone, ensure your messages are like an efficient light bulb -
optimise for light, not heat.

Thanks,

Dave.

On Wed, 27 Mar 2019 at 21:25, Evgeny  wrote:

> On Wed, Mar 27, 2019 at 11:17 PM, carlo von lynX 
> wrote:
> > XMPP will be nearly completely dead in coming years
> > as it has always refused to change the fundament of its
> > inflexibility
>
> Hey, dude, how is your psyced going? Oh, it's dead. Okay.
>
> ___
> 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] One true final way to mark up messages

[Dave Cridland]

On Wed, 27 Mar 2019 at 18:25, Sam Whited  wrote:

> On Wed, Mar 27, 2019, at 17:14, W. Martin Borgert wrote:
> > 0393 is not bad, IMHO. It might need two or three additions, esp.
> > hyperlinks, but most typical use cases are covered.
>
> What is the use case for hyper links and who does it benefit? I
> keep hearing people say they want them, but I don't really
> understand why they're necessary over just auto linking things that
> look like URLs. Thanks.


URLs are often frustratingly long, and they're also surprisingly difficult
to pick out of text unless the longhand formal syntax is used. Real users
often do not send those, instead sending a bare domain - or just a typo
missing a space after the period.which often gets highlighted as a URL...

Many consumer systems I've been playing with recently instead have a formal
"link" construct that's sent alongside the message, much like Andrew's
suggesting here.

An exception, as you point out elsewhere, is Slack - but Slack is
fascinating in its demographics. It's the darling of tech and finance
departments everywhere, but our sales department hates it - it is not the
model you want to follow for consumer-grade social IM.

In any case, we're neither trying to replicate any particular existing
system, nor taking Andrew's suggestions and immediately pushing them
through to Draft.

I said before (but foolishly replied and thus quoted his monster message in
entirety), I think there's a few things we can very usefully draw from the
message:

1) It makes an excellent list of requirements for a modern consumer-grade
social IM.

2) Some of the details are things missing from our current stack. I'm
thinking that "legacy" trick, for example.

3) I don't think Andrew's assertion that our current (partial?) solutions
for his requirements are an overlapping mess ought to be discarded out of
hand. Cleaning these things up might make a lot of sense.

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

Re: [Standards] UPDATED: XEP-0412 (XMPP Compliance Suites 2019)

[Dave Cridland]

On Tue, 26 Mar 2019 at 16:44, Jonas Schäfer  wrote:

> Version 0.5.0 of XEP-0412 (XMPP Compliance Suites 2019) has been
> released.
>
> Abstract:
> This document defines XMPP protocol compliance levels.
>
> Changelog:
> * Taken over ownership.
> * Improved structure of category and level names.
> * Added XEP-0313 and XEP-0412 to 'Advanced Group Chat' (gl)
>

We've added the requirement of XEP-0412 to XEP-0412? Was this meant to be
XEP-0410?


>
> URL: https://xmpp.org/extensions/xep-0412.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
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313 / XEP-0359 interaction

[Dave Cridland]

On Mon, 25 Mar 2019 at 14:03, Florian Schmaus  wrote:

> On 25.03.19 13:52, Dave Cridland wrote:
> >
> >
> > On Mon, 25 Mar 2019 at 12:26, Florian Schmaus  > <mailto:f...@geekplace.eu>> wrote:
> >
> > On 25.03.19 12:48, Guus der Kinderen wrote:
> > > XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359
> > > "Unique and Stable Stanza IDs" to identify content in the archive.
> > >
> > > MAM provides an archive on the server, which can be efficiently
> > > synchronized with a client-sided archive. It does this using the
> IDs
> > > from XEP-0359. It's a simple query: the client provides an ID of a
> > > message in the archive, the server responds with all later
> messages.
> > >
> > > Although this is a simple, elegant solution, it breaks when the
> client
> > > receives messages that have XEP-0359 IDs, but are not part of the
> > > (server-sided) archive. This puts quite a restrication on XEP-0359
> use
> > > in other contexts than MAM. Can this be improved upon?
> >
> > I think some more context could be helpful. As far as I know this
> come
> > up yesterday (?) in the xsf@ MUC in a discussion between Guus and
> MattJ
> > (and waqas).
> >
> > As far as I understood it, prior MAM versions used an 
> > element which not only contains the ID of the message stanza in the
> > archive but also carries the semantic that the message was actually
> > archived.
> >
> > Now Guus wants for some reason to slap a  on every
> message,
> > irregardless if it was archived or not. MattJ argued that this would
> > break client's assumption that messages with a  are
> actually
> > archived. This assumes that clients simply remember the last
> stanza-id
> > of the message they received and perform a resync of the archive when
> > they come online again.
> >
> > Keep in mind that MAM archives may not archive every message stanza,
> > think of IBB messages and the like.
> >
> > I do not claim to understand every statement and argument in this
> > discussion, so please correct me if I am wrong. I am also not sure if
> > the problem is an actual problem: There was a interesting discussion
> > between MattJ and waqas regarding the guarantees client developers
> can
> > expect from a MAM archive.
> >
> > But what I understood is when XEP-MAM switched from  to
> >  there possibly, depending on the guarantees you expect
> from
> > MAM, was a loss of semantic.
> >
> > I see multiple potential solutions:
> >
> > 1. Introduce an archived flag
> > 2. Use 's 'by' attribute to carry the archived or not
> > semantic
> > 3. Potential others
> >
> > I lean towards 2. Which could mean that
> >
> >  > to='u...@example.com <mailto:u...@example.com>'>
> >   
> > 
> >
> > does not indicate archival of the message into u...@example.com
> > <mailto:u...@example.com>'s MAM
> > archive, while
> >
> >  > to='u...@example.com <mailto:u...@example.com>'>
> >   
> > 
> >
> > does.
> >
> >
> > Ah, so the first suggests the message is archived by the server-level
> > archive?
>
> I'd say it depends whether "example.com" announces the MAM disco#info
> feature. And I also believe that this does not automatically imply for
> the receiving entity that it has access to that message in the archive
> (if there is one).
>
>
Ah, so the semantics of XEP-0359 vary depending on an unrelated
specification not referenced by the document in ways that are not specified
in either document?

Glad that's clear then. :-)


> - Florian
>
> ___
> 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-0313 / XEP-0359 interaction

[Dave Cridland]

On Mon, 25 Mar 2019 at 12:26, Florian Schmaus  wrote:

> On 25.03.19 12:48, Guus der Kinderen wrote:
> > XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359
> > "Unique and Stable Stanza IDs" to identify content in the archive.
> >
> > MAM provides an archive on the server, which can be efficiently
> > synchronized with a client-sided archive. It does this using the IDs
> > from XEP-0359. It's a simple query: the client provides an ID of a
> > message in the archive, the server responds with all later messages.
> >
> > Although this is a simple, elegant solution, it breaks when the client
> > receives messages that have XEP-0359 IDs, but are not part of the
> > (server-sided) archive. This puts quite a restrication on XEP-0359 use
> > in other contexts than MAM. Can this be improved upon?
>
> I think some more context could be helpful. As far as I know this come
> up yesterday (?) in the xsf@ MUC in a discussion between Guus and MattJ
> (and waqas).
>
> As far as I understood it, prior MAM versions used an 
> element which not only contains the ID of the message stanza in the
> archive but also carries the semantic that the message was actually
> archived.
>
> Now Guus wants for some reason to slap a  on every message,
> irregardless if it was archived or not. MattJ argued that this would
> break client's assumption that messages with a  are actually
> archived. This assumes that clients simply remember the last stanza-id
> of the message they received and perform a resync of the archive when
> they come online again.
>
> Keep in mind that MAM archives may not archive every message stanza,
> think of IBB messages and the like.
>
> I do not claim to understand every statement and argument in this
> discussion, so please correct me if I am wrong. I am also not sure if
> the problem is an actual problem: There was a interesting discussion
> between MattJ and waqas regarding the guarantees client developers can
> expect from a MAM archive.
>
> But what I understood is when XEP-MAM switched from  to
>  there possibly, depending on the guarantees you expect from
> MAM, was a loss of semantic.
>
> I see multiple potential solutions:
>
> 1. Introduce an archived flag
> 2. Use 's 'by' attribute to carry the archived or not semantic
> 3. Potential others
>
> I lean towards 2. Which could mean that
>
> 
>   
> 
>
> does not indicate archival of the message into u...@example.com's MAM
> archive, while
>
> 
>   
> 
>
> does.
>
>
Ah, so the first suggests the message is archived by the server-level
archive?


> - Florian
>
> ___
> 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] Council Voting Summary 2019-03-17

[Dave Cridland]

On Sat, 23 Mar 2019 at 09:14, Evgeny  wrote:

> Hey, Georg, Dave.
>
> I think I have addressed all your concerns in my new local copy [1]
>
> [1] http://upload.zinid.ru/xep-eax-cir.html
>
>
Thanks, but for the avoidance of doubt, I had no concerns that needed to be
addressed prior to adoption.


> ___
> 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] Council Voting Summary 2019-03-17

[Dave Cridland]

On Fri, 22 Mar 2019 at 09:05, Evgeny  wrote:

>
>
> On Fri, Mar 22, 2019 at 11:29 AM, Georg Lukas  wrote:
> > * Tedd Sterr  [2019-03-17 21:53]:
> >>  Proposed XMPP Extension: E2E Authentication in XMPP: Certificate
> >> Issuance and Revocation -
> >> https://xmpp.org/extensions/inbox/eax-cir.html
> >
> > +1
>
> Thank you very much for the thorough review.
>
> >
> > - A CA doesn't _need to_ be a server entity. It's well possible for a
> > CA
> >   to be a bot@domain/resource or a component.domain, as long as it's
> >   ensured that the respective server is configured to enforce s2s (and
> >   c2s) TLS and to check server certificates.
>
> I was thinking about this. The terminology in the XEP becomes more
> complex. How to name this stuff? CA XMPP entity? But this is a cosmetic
> issue of course.
>
>
You can just have a note somewhere that says "All examples, and much the
the terminology, assumes that a CA is hosted on a XMPP server entity
addressed by a domain-style Jid; this is not a requirement of the protocol,
and a CA MAY be addressed by any valid Jid, including local@domain or even
local@domain/resource."


> >
> > - I'm not sure what is gained by stripping the PEM BEGIN/END headers.
> >   IMO It's not worth optimizing for two lines at the cost of increased
> >   client and server complexity.
>
> Without PEM encapsulation boundaries it's just a Base64 encoded DER
> stuff. So you can use Base64 codec for this, not full blown PEM codec
> which should parse and understand the boundaries and which can run into
> compatibility problems (due to historic reasons outlined in RFC7468).
> Also, in other places, such as the signature element, it's just base64
> encoded binary, so we will run into consistency problems, although
> cosmetic, but still.
>
> I can probably just to reform the phrase and say that it's Base64
> encoded DER ASN.1 stuff. Note also, that understanding full PEM
> encoding is not required by the document (all those places are SHOULD
> or RECOMMENDED or some such).
>
>
Yes, I hadn't actually noticed you'd said "PEM without headers". I'd prefer
specifying just base64 DER. While these are the same thing in principle, I
think it clarifies things enormously.

(I actually just glanced at the base64, saw the opening, and recognised
certificates in base64-encoded DER - I've obviously spent too long on this
stuff before).


> >
> > - Signing Request: I'm not very happy with using IQs for the request
> > and
> >   response, because there is an optional message-based manual
> > challenge
> >   step in between, essentially meaning that the IQ request must be
> > sent
> >   with an infinite timeout. OTOH, replacing this flow with something
> >   like data forms / ad-hoc commands might make things even more
> > complex.
>
> Timeouts during a challenge procedure is indeed a problem. However, I
> don't see how this can be overcome by using data forms or other
> stanzas. I think a client should render "Cancel" button when it has run
> an URL handler and wait indefinitely. And yes, the complexity.
>
>
I did wonder, actually, about seperating the CSR submission from the
processing.

The spec as written more or less assumes a short, online interaction - if
you assume lots of manual intervention and an offline CA, I think this
becomes rapidly impractical.

What about an IQ which creates the signing request with a CSR, and returns
an id which can be queried about status? The query could trigger resending
any pending challenges, too, as well as delivering the certificate.


> >
> > - Is there a specific reason for mandating the @by in the error
> >   response, in addition to the IQ @from?
>
> Probably it's not, I can remove it. It has left from the previous
> version of the document.
>
>
I'd drop it to a SHOULD rather than removing it. It's always useful to know
whose error it is.


> >
> > - §8.1: it should be explicitly stated that this part replaces the
> >   XEP-0077 IBR workflow and not extends it. Also that by using this
> >   mechanism, the account does not have a password and that the only
> > way
> >   to register another device is to copy over the private key.
>
> In recent version of the document [1] (which is only a local copy that
> I'm going to submit later) I address this problem and X.509 IBR can be
> used to recover access to the account without copying keys.
> And yes, I can add the statement.
>
> >
> > - §9: 'id' attribute of the  element MUST contain first 16
> > octets
> >   from a signatureValue" - if this is required for interop, it should
> > be
> >   "MUST equal to", otherwise it might as well allow shorter @ids, eg.
> >   urls-safe-base64.
>
> Okay, whatever. I don't oppose, I'll change it. Although I personally
> don't see the difference, probably it's lost in translation.
>
> [1] http://upload.zinid.ru/xep-eax-cir.html#acc-recovery
>
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: 

Re: [Standards] MIX

[Dave Cridland]

On Mon, 18 Mar 2019 at 18:08, Ralph Meijer  wrote:

> 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.
>

Yeah, and bots, and so on. I'm convinced we need the functionality as-is.

> * 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.
>
>
Indeed, many XML nodes are named "node", to reflect both nodes and nodes -
though we never encode the node identifier in the node, which is
interesting, and rarely transport nodes on their own, so nodes never
contain nodes (but nodes named "node" of course, contain nodes).

You're right, we should stick to calling them node, there's less chance of
confusion. :-)


>
> > * 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.
>
>
I thought that was clear enough from the text. Archives of other streams
are considerably more niche, at least for the most part.


> 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. :-(
>
>
Yes - also, if you have multiple clients, and on some of those you don't
normally catch-up on most chatrooms, do you want those clients to have to
get all the chatroom traffic during catch-up?

> * 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?
>

Given a message, (some/many/rare) clients need to know who actually sent
the message.

This means knowing detailed information about the sender - we can do this
in (roughly) three ways:

* Include the key information in the message itself. This is roughly what
we're doing in the  element currently.
* Include pointers to the information. MUC does this pattern, but it
suffers where the pointer expires (points to someone who is no longer an
occupant/participant)
* Include pointers to the information and expect client to locate that
information in the *archive* of the participants node.

MIX started off on the third option and has moved to the first, generally.


>
>
> > * 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.
>
>
You're allowed to disagree. Someone has to be wrong, after all. :-)


>
> > * 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 for non-anonymous MIX channels, and are in any case only used
> > in '404 for private messaging (I think!).
>
> What are you suggesting instead then?
>
>
If you have the stable identifier - and I think we actually always do -
then you can derive the jid if its hidden, and you need it. But you really
only ever need  for anonymous senders.


>
> > * Having messages come from the channel jid allows for lots of
> > flexibility, but does mean that in the "classic" chatroom case it's
> > harder for clients to block participants without blocking the entire
> > chatroom. That said, a 

Re: [Standards] MIX

[Dave Cridland]

On Mon, 18 Mar 2019 at 17:07, Steve Kille  wrote:

> Dave,
>
>
>
> Thanks for all this input.   Let me go over it.
>
>
>
>
>
> *From:* Standards  *On Behalf Of *Dave
> Cridland
> *Sent:* 12 March 2019 12:01
> *To:* XMPP Standards 
> *Subject:* [Standards] MIX
>
>
>
> Hi all,
>
>
>
> I've been writing a quick and dirty implementation of MIX.
>
>
>
> So far, I've started with an even quicker and dirtier PubSub, and glued in
> the MIX stuff on top. There's no MAM etc yet.
>
>
>
> The following are comments I've had so far, in no particular order:
>
>
>
> *  is sent to the sender for correlation. This assumes
> that messages sent from all the user's clients will have unique message ids
> - that's a stronger requirement than RFC 6120 dictates. It feels as though
> this could include the original full jid as well - or perhaps even instead
> - and might benefit from using the  element already defined
> elsewhere.
>
> *[Steve Kille]*
>
> *I didn’t know about .  This is sensible, and also avoids the
> need for any special handling for the sender copy. *
>
> *Have removed  and added reference to XEP-0359*
>
>
>

That would, mind, be a breaking change - so I hope you're bumping the
namespace.


>
>
> * Section 7.2 stipulates that archiving of all messages is mandatory - did
> you really mean that?
>
> *[Steve Kille]*
>
> *This is needed for MUC compatibility.   However,  I think there are
> sensible non-archive use cases, so I’ve added text to relax this, but
> clearly warn of the “MUC Service” requirements.*
>
>
>

MUC requires the last N messages to be kept if a history replay on join is
desired, but nothing beyond that.

But archiving isn't always desirable, indeed.


> * 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.
>
> *[Steve Kille] *
>
> *I can’t see any complexity as a consequence of this.  Use case for no
> subscriptions is minimal, but might be wanted for a client that needs to
> send, but not receive.*
>
>
>

Ah, yes - that's the use-case I wasn't thinking of.


> *The complex bit is when you ask to subscribe to multiple nodes and there
> are ACI issues.   I don’t think any change is needed*
>
>
>
>
>
> * I'd dearly love to s/node/stream/ for the nodes within a channel.
>
> *[Steve Kille]*
>
> *It would be neat, as stream is a clean way to think of things.  But
> PubSub has nodes, not streams.*
>
>
>

Everything has nodes in XMPP. Even at the XML level.


>
>
> * 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.
>
> *[Steve Kille]*
>
> *This model seems to arise naturally from the MIX-PAM model.   Every
> message is sent to every client.   It feels right to keep a copy at the
> client’s server, particularly to efficiently support multiple clients.   It
> also works well if servers don’t have 24x7 connectivity.*
>
>
>
> *I do think we want to support the model of MIX-PAM server doing the
> archive.   We could explicitly support both models, and have a MIX-PAM
> capability, so that the client does not have to guess.   What do you think?*
>
>
>

I think we always support both models implicitly. The issue is that the
client has to guess which one to use, so MIX-PAM has to be able to tell the
client when it joined. Efficient support of clients and slow links probably
means that we need to do both, but it feels like an area where we could
improve - perhaps MIX-PAM could mediate MAM queries and service them from
the local cache if available, rather than just dumping messages unfiltered
into the "general" MAM?


>
>
> * 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?
>
&

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

[Dave Cridland]

On Thu, 14 Mar 2019 at 15:12, Peter Saint-Andre  wrote:

> On 3/14/19 6:17 AM, Dave Cridland wrote:
> >
> >
> > On Thu, 14 Mar 2019 at 11:25, Ненахов Андрей
> > mailto:andrew.nenak...@redsolution.ru>>
> > wrote:
> >
> >
> > People send comments on the list, and we answer their questions,
> > propose
> > modifications to the text of the document, submit or process pull
> > requests, etc. For a small spec like this, it should be pretty
> > simple.
> > Plus if you are a co-author if you will be famous forever. ;-)
> >
> >
> > Ok, I think I can handle it. Plus, vanity is my favourite sin.
> >
> >
> > It used to be mine until Carly Simon wrote a song about me.
>
> Dave, how old were you in 1971? ;-)
>
>
She was always ahead of her time.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

[Dave Cridland]

On Thu, 14 Mar 2019 at 15:14, Peter Saint-Andre  wrote:

> On 3/14/19 5:05 AM, Dave Cridland wrote:
> >
> >
> > On Wed, 13 Mar 2019 at 21:46, Ralph Meijer  > <mailto:ral...@ik.nu>> wrote:
> >
> > On 13/03/2019 22.16, Kevin Smith wrote:
> > >
> > >
> > >> On 13 Mar 2019, at 17:37, Peter Saint-Andre  > <mailto:stpe...@mozilla.com>> wrote:
> > >>
> > >> I can help, but I would not object to adding a more active
> co-author
> > >> (preferably an implementor of the spec).
> > >
> > > Do you want to request a last call? Under the new rules Council
> > aren’t allowed to trigger an LC any more unless either the authors
> > request it or the authors abandon the XEP.
> >
> > Kev,
> >
> > I think this is a very narrow reading of the new text, and I don't
> > agree
> > that this says the Approving Body cannot issue (=/= trigger) a Last
> > Call, via the Editor, if it so sees fit. What the changed text is
> meant
> > to ensure is that once a Last Call is issued, there's somebody,
> either
> > an author or document shepherd, to process feedback of that Last Call
> > and during the approval process of the Approving Body. And that
> there's
> > a defined way to propose advancement by authors, or others in case it
> > appears that the authors are no longer interested in such
> advancement.
> >
> > If you think this new wording suggests that the Approving Body (in
> this
> > case Council) is no longer in full control of the process, then
> please
> > propose changes so this can be rectified.
> >
> >
> > I think the way that XEP-0001 is currently written suggests that if the
> > Council triggered a Last Call without the author(s) involved, the
> > Author(s) could complain on the grounds that we have not followed
> > XEP-0001 as written.
>
> Has this ever happened or is it purely hypothetical?
>
>
It is hypothetical. Hopefully it will remain so.


> > Since we do not have a complaints procedure, what happens then is
> > anyone's guess. (I think they need to complain to the Board, and if that
> > fails to achieve a resolution, to the Members - but that's a suggestion
> > and is in no way supported by any of our process documents).
>
> It seems to me that the Board is the appropriate escalation path,
> although raising an issue among the membership would also work.
>
> Personally I don't see the need for every possible eventuality to be
> captured in process documents...
>

No, me neither, but I go back and forth over whether we should have some
kind of appeals process for where people think Council actions are "Wrong"
- it'd be painful to have to figure one out on the fly, anyway. Based on my
actions so far, I don't feel this way strongly enough to act, obviously. :-)

What I do feel relatively strongly about is that we should document what we
do, and in return do what we document. This seems to me to be a basic tenet
of the "Open" bit of "Open Standards".

So we've followed the process, and I'll get a vote for Last Call on '353
done next meeting.

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

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

[Dave Cridland]

On Thu, 14 Mar 2019 at 11:25, Ненахов Андрей 
wrote:

>
> People send comments on the list, and we answer their questions, propose
>> modifications to the text of the document, submit or process pull
>> requests, etc. For a small spec like this, it should be pretty simple.
>> Plus if you are a co-author if you will be famous forever. ;-)
>>
>
> Ok, I think I can handle it. Plus, vanity is my favourite sin.
>

It used to be mine until Carly Simon wrote a song about me.

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

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

[Dave Cridland]

On Wed, 13 Mar 2019 at 21:46, Ralph Meijer  wrote:

> On 13/03/2019 22.16, Kevin Smith wrote:
> >
> >
> >> On 13 Mar 2019, at 17:37, Peter Saint-Andre 
> wrote:
> >>
> >> I can help, but I would not object to adding a more active co-author
> >> (preferably an implementor of the spec).
> >
> > Do you want to request a last call? Under the new rules Council aren’t
> allowed to trigger an LC any more unless either the authors request it or
> the authors abandon the XEP.
>
> Kev,
>
> I think this is a very narrow reading of the new text, and I don't agree
> that this says the Approving Body cannot issue (=/= trigger) a Last
> Call, via the Editor, if it so sees fit. What the changed text is meant
> to ensure is that once a Last Call is issued, there's somebody, either
> an author or document shepherd, to process feedback of that Last Call
> and during the approval process of the Approving Body. And that there's
> a defined way to propose advancement by authors, or others in case it
> appears that the authors are no longer interested in such advancement.
>
> If you think this new wording suggests that the Approving Body (in this
> case Council) is no longer in full control of the process, then please
> propose changes so this can be rectified.


I think the way that XEP-0001 is currently written suggests that if the
Council triggered a Last Call without the author(s) involved, the Author(s)
could complain on the grounds that we have not followed XEP-0001 as written.

Since we do not have a complaints procedure, what happens then is anyone's
guess. (I think they need to complain to the Board, and if that fails to
achieve a resolution, to the Members - but that's a suggestion and is in no
way supported by any of our process documents).

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

Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft

[Dave Cridland]

Philipp, Peter,

Do either of you want to remain involved with this one?

Andrew,

If they don't, would you be able to handle processing Last Call feedback?

On Wed, 13 Mar 2019 at 13:14, Ненахов Андрей 
wrote:

> Hello, everyone.
>
> Could we please advance XEP-0353: Jingle Message Initiation
>  to draft, please?
>
> We need it because bare XEP-0166 does not work well with push
> notifications, and does not support 'ring an all devices' behaviour.
>
>
> --
> Andrew Nenakhov
> CEO, Redsolution, Inc.
> 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
___

[Standards] MIX

[Dave Cridland]

Hi all,

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

So far, I've started with an even quicker and dirtier PubSub, and glued in
the MIX stuff on top. There's no MAM etc yet.

The following are comments I've had so far, in no particular order:

*  is sent to the sender for correlation. This assumes that
messages sent from all the user's clients will have unique message ids -
that's a stronger requirement than RFC 6120 dictates. It feels as though
this could include the original full jid as well - or perhaps even instead
- and might benefit from using the  element already defined
elsewhere.

* Section 7.2 stipulates that archiving of all messages is mandatory - did
you really mean that?

* 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.

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

* 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.

* 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?

* 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. MIX has lent toward both those options over its
development, currently leaning toward the latter. Should we just include
the participant element in the outgoing messages, instead of duplicating
its contents? Should we have a all-participants node containing every
participant ever (so a get-item is simple for lookup)? Should MIX messages
include the stable participant id?

* 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.

* 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
for non-anonymous MIX channels, and are in any case only used in '404 for
private messaging (I think!).

* Having messages come from the channel jid allows for lots of flexibility,
but does mean that in the "classic" chatroom case it's harder for clients
to block participants without blocking the entire chatroom. That said, a
MIX-aware server can help here, and a MIX-unaware server would struggle
more in this case I think, which brings me onto:

* I think MIX can be made to work (albeit less efficiently) without MIX-PAM.

This last point needs a detailed explanation, of course, both in terms of
motivation and design.

Firstly, the motivation here is that currently, MIX needs a substantial
fork-lift upgrade to get deployed. Every entity on the path of MIX needs to
implement, and deploy, some MIX in order to work. The benefit of this is
obvious, of course - it means an efficient, and very solid, design, and
it's certainly where we need to get to. But getting There form Here is
going to be difficult, since who wants to implement MIX in their client if
the servers need to support it, and so on.

By having MIX channel servers able to directly interoperate with MIX
clients even if the home server doesn't support MIX, I think we're able to
accelerate deployment.

The changes needed are:

a) A MIX client needs to determine if its home server supports MIX-PAM. If
it does not, a "Direct Join" is used - which is simply exactly the same
join but sent directly to the MIX with full jids.

b) A MIX channel receiving a direct join implies the client's home server
does not support MIX-PAM. It then uses bare Jids in its Participants items
still, but sends messages addressed to the full jid of such clients.

c) When reconnecting, a MIX client which has performed a direct join in a
previous session may have to leave and rejoin - assuming it cannot maintain
the same resource.

Dave.
___
Standards mailing list
Info: 

Re: [Standards] Third month with no updated compliance suites

[Dave Cridland]

On Mon, 4 Mar 2019 at 10:13, Severino Ferrer de la Peñita 
wrote:

> On Monday, March 4, 2019 5:42:24 AM CET Ненахов Андрей wrote:
> > I think that the whole idea of making compliance suites as a xep is
> flawed
> > and creates unnecessary bureaucracy for bureaucracy sake.
> >
> > It could have been just a page on xmpp.org website, listing XEPs that
> > council currently consideres part of a compliance suites. No bureaucracy,
> > no need to update them every year, win-win for everyone.
> >
> > If someone won't be happy with just a current list, well, add versions to
> > it, in the simplest way possible.
>


> I've been asked this a couple of times as well, why the compliance suite
> is
> not a page at xmpp.org with the current situation instead of a XEP.
> People usually assume XEPs are protocol specifications to be implemented.
>

People are wrong. :-)

The XEPs are our formal documents, and contain not just protocol
specifications but any document that has general consensus and formal
approval of the XMPP Standards Foundation. We have no other process for
making that happen, and I'm really loathe to put ourselves in a position
where we need to create a new process in order to manage a new type of
document. We cannot, certainly, claim to be an "Open Standards" group if we
don't have an open process for changing a document.

But if people want the compliance suites to be on the front page of the
website, I'm all for linking them there.

We can (and have, several times) altered the formatting of XEPs to make
them more approachable - most of the boilerplate now lives at the end of
the documents in appendices, for example. If someone want to provide some
new CSS/XSLT to improve the formatting, I'm all in favour.

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

Re: [Standards] Third month with no updated compliance suites

[Dave Cridland]

Who are you arguing *with*?

I agree it's ridiculous, but I also note that the number of comments on the
2019 one is considerably below 20, and possibly less than 15, depending on
how one counts. The number of people involved in the discussion outside
Council is less than 5 (and I'm including your comments here, which are
simply that we should have some Compliance Suites).

If the community isn't interested in working on these, I'm not sure how we
advance them faster.

Dave.

On Sat, 2 Mar 2019 at 19:14, Sam Whited  wrote:

> I'd like to point out that it's now the third month of 2019 and the 2018
> compliance suites are still the ones that appear to be accepted (even
> though, confusingly, they also say "draft" on them):
>
> https://xmpp.org/extensions/xep-0387.html
>
> As I've argued before, this looks ridiculous and should be fixed *before*
> the year in the title starts.
>
> —Sam
> ___
> 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] Extending XEP-0085 Chat State Notifications, again

[Dave Cridland]

On Fri, 1 Mar 2019 at 08:35, Ненахов Андрей 
wrote:

> This was discussed in July 2018 and, I guess, moved nowhere, but I'll
> raise the issue once again. Any decent messenger bar XMPP based ones have
> capabilities to signal type of user activity beyond just "composing a
> message", but also "recording voice message", "recording video message",
> "uploading file", 
>
> We NEED that in our clients, and, subsequently, we'd prefer it to be an
> XMPP standard.
>
> So far we've extended XEP-0085 by adding a "type" attribute to 
> element:
> from='berna...@shakespeare.lit/pda'
>to='franci...@shakespeare.lit/elsinore'
>type='chat'>
> 
> 
>
>
Counter-proposal:


  


I believe this should work fine and means we're not changing XEP-0085
(which is, indeed, Final).


> Works OK by us and it does not break any clients with XEP-0085 that we
> know of.
>
> However, last time when this matter was raised, there were objections that
> 0085 is 'final' and therefore we can't change anything because of reasons
> and was essentially discarded. Hope this time it'll be different.
>
> --
> Andrew Nenakhov
> CEO, Redsolution, Inc.
> 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
___

[Standards] Council Agenda 2019-02-06

[Dave Cridland]

The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1600 UTC. The agenda is collated from (in order of reliability):
* Github pull requests and issues marked "Needs Council":
https://github.com/xsf/xeps/labels/Needs%20Council
* Random mails from Standards List
* Random suggestions directly to me

I (try to) send out the final agenda about 24 hours in advance.

Agenda as follows:

1) Roll Call

2) Agenda Bashing

a) Possible missing items. Feel free to reply to this email in advance of
the meeting.

b) The likelyhood of errors is high.

3) Items for voting:

a) #739: XEP-0410: pre-LC and LC feedback

   https://github.com/xsf/xeps/pull/739

b) #752: XEP-0410: add application-specific  condition

   https://github.com/xsf/xeps/pull/752

c) Advance XEP-0410 to Draft

  https://xmpp.org/extensions/xep-0410.html

d) #745: XEP-0234: Use  to signify the hash function being
used, instead of an (invalid) empty 

   https://github.com/xsf/xeps/pull/745

e) Adopt Proposed XMPP Extension: XMPP Over RELOAD (XOR)

  Abstract:
This specification defines an XMPP Usage of REsource LOcation And
Discovery (RELOAD). The XMPP usage provides an ability for XMPP
clients to discover other peers' location through the peer-to-peer
overlay. Once a peer location is determined, the RELOAD AppAttach
method is used to establish a direct connection between peers through
which XMPP streams are exchanged.

  https://xmpp.org/extensions/inbox/xor.html

f) #744: XEP-0001: Clarify proposing Deferred XEPs for advancement to Draft

  https://github.com/xsf/xeps/pull/744

g) #746: XEP-0060: Add missing @publisher in pubsub schema

  https://github.com/xsf/xeps/pull/746

h) #747: XEP-0084: Bump the maximum of @width and @height to 65535

  https://github.com/xsf/xeps/pull/747

4) Outstanding Votes

5) Next Meeting

6) AOB

7) Close

Note that I'm aiming for 30 minutes.

Meetings are normally held every Wednesday at 1600 UTC in the
xmpp:coun...@muc.xmpp.org?join
 chatroom.
Meetings are open, and anyone
(XSF Member or not) may attend, though only XMPP Council members may
vote. Relevant comments from the floor are welcomed.

Thanks,

Dave.
(As Council Chair).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: XMPP Over RELOAD (XOR)

[Dave Cridland]

This looks very interesting - I'd not come across RELOAD before.

I'd note that the extent and complexity of this proposal means that the
Experimental phase is likely to be quite long, and I'm not clear if there's
enough interest for advancing, but I don't see any blockers for adoption as
a XEP.

On Mon, 4 Feb 2019 at 19:20, Jonas Schäfer  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: XMPP Over RELOAD (XOR)
> Abstract:
> This specification defines an XMPP Usage of REsource LOcation And
> Discovery (RELOAD). The XMPP usage provides an ability for XMPP
> clients to discover other peers' location through the peer-to-peer
> overlay. Once a peer location is determined, the RELOAD AppAttach
> method is used to establish a direct connection between peers through
> which XMPP streams are exchanged.
>
> URL: https://xmpp.org/extensions/inbox/xor.html
>
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> 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] Council Voting Summary 2019-02-03

[Dave Cridland]

On Mon, 4 Feb 2019 at 19:41, Jonas Schäfer  wrote:

> On Sonntag, 3. Februar 2019 18:18:20 CET Tedd Sterr wrote:
> > PR #743 - XEP-0156: Add implementation notes suggesting CORS -
> > https://github.com/xsf/xeps/pull/743 Dave: +1 (doesn't actually
> recommend *
> > just uses it as an example, this is equivalent data DNS SRV/TXT records,
> so
> > I don't see a problem) Georg: [on-list] (CORS headers are a Security, and
> > just allowing * is probably a dumb idea) Jonas: [on-list] (because of
> what
> > Georg said)
> > Kev: +1
> > Link: +1
>
> I don’t have the web knowledge or the motivation to write out a good
> paragraph
> which handles this. As a workaround, I’d be fine if one simply deletes the
> example and leave the rest as-is.
>
>
Could you articulate what you think the problem with '*' is?


> kind regards,
> Jonas___
> 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] Summit Agendum: Message IDs

[Dave Cridland]

On Tue, 29 Jan 2019, 18:01 Sam Whited  On Tue, Jan 29, 2019, at 17:41, Dave Cridland wrote:
> > a) Clients can make some assertion that they will generate a
> > globally-unique @id on stanzas.
>
> I like that, but would servers now have to remember which messages were
> sent by clients that advertised this feature and which weren't? I'm not
> sure that's the end of the world, but it can't be applied retroactively
> (whereas origin-id is on each message, so a server that adds support later
> can know which messages in an archive should already have globally unique
> IDs).
>

Ah, I was thinking that we'd do this on a hop-by-hop basis. So clients
advertise only to their servers, and the servers advertise to each other.

But I think message archiving might remain a case where we need to use
stanza-ids - I know I said we'd ignore the case of a malicious attacker,
but we definitely don't want an attacker to overwrite or simply corrupt an
archive.

Of course, we could use a mandated format for ids which includes the jid,
but that doesn't work with MUC etc. And interesting alternative is if the
MAM service uses a derived id tuple of (from,id) - in that case I *think*
it's safe to use stanza ids, as long as the servers and clients are all
advertising our new feature *or* there's some kind of workaround.

Sorry, I'm thinking aloud and being *very* unclear.

That's why I had the servers handle non-conforming clients:


> > b) Servers can also advertise assertions that they, too, deal with
> > globally unique stanzas identifiers. If a connected client fails to
> > make the assertion, the server either:
> >
> > i) Injects a stanza-id of its own, or:
>
> If we're going to have to fall back to this, maybe we should just always
> use stanza-id so that we don't have to determine if the id attribute or the
> stanza-id should be used.
>

Yeah. It's a bit rubbish, and I don't like this option.


> > ii) Changing the @id and encodes the original @id within it, somehow.
> > (They could use any scheme for that, and might want to consider
> > something that's difficult or impossible to emulate).
>
> What does encoding the original ID in it get us? Does the server need to
> know the original ID later for some reason? Clients presumably wouldn't be
> able to use this value if a message is reflected; if they added support for
> this presumably they'd just add support for globally unique IDs.
>

Well, I was thinking it would be reversible. So if a server receives a
"response" type - error, or result - it can reverse the mapping and give
the client the id it used.

Externally, it'd look like the client used unique ids everywhere and
consistently - but the client's view of its own stanzas would be unchanged.


> > c) MUC services (and similar broadcasters) advertise a "stable
> > identifier" thing. Since @id's are now globally unique, they can be
> > passed through - but a MUC service faced with a server that isn't
> > asserting the Thing can choose to override the @id.
>
> Same as above. Does this make it harder (impossible?) for clients to
> associate reflections with the original message?
>

I think - and I may be wrong - that it'd be fairly easy to use the same id
on the reflection itself.


> > d) If a server is doing the id thing, and a client asserts same, and
> > fails to include an @id on any stanza, that stanza is bounced.
>
> This seems sane.
>
> —Sam
> ___
> 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] Council Voting Summary 2019-01-29

[Dave Cridland]

Thanks for this.

On Tue, 29 Jan 2019 at 23:04, Tedd Sterr  wrote:

> *2019-01-09 (expired 2019-01-23)*
>
> PASSED (-0:1:+4)
> *Proposed XMPP Extension: Order-By* -
> https://xmpp.org/extensions/inbox/order-by.html
> Dave: +0 (reserve the right to change that while others are still on-list)
> Georg: +1 (still have detail objections, but not enough to reject;
> interested in seeing how it develops)
> Jonas: +1 (useful as-is; could imagine generalising to all types of result
> sets, e.g. disco#items on MUC)
> Kev: +1 (not keen on it, but it clears the bar-of-incompetence for
> Experimental)
> Link: +1
>
> FAILED (-0:4:+1)
> *PR #715 - XEP-0045: Add missing disco#info feature to example 4, 9, 78
> and 218* - https://github.com/xsf/xeps/pull/715
> Dave: -0
> Georg: -0 (I like my examples short and focused)
> Jonas: -0
> Kev: -0 (Don't care)
> Link: +1
>
>
> *2019-01-16 (expiring 2019-01-30)*
>
> *Proposed XMPP Extension: Cryptographic Hash Function Recommendations for
> XMPP* - https://xmpp.org/extensions/inbox/hash-recommendations.html
> Dave: [on-list] (+0 for now)
> Georg: +1
> Jonas: +1 (obviously)
> Kev: +1
> Link: +1
>
>
+1


>
> *2019-01-23 (expiring 2019-02-06)*
>
> *PR #743 - XEP-0156: Add implementation notes suggesting CORS* -
> https://github.com/xsf/xeps/pull/743
> Dave: [pending]
> Georg: [on-list] (CORS headers are a Security, and just allowing * is
> probably a dumb idea)
> Jonas: [on-list] (because of what Georg said)
> Kev: +1
> Link: +1
>
>
+1 - it doesn't actually recommend "*", it just uses it as an example - but
this is equivalent data to that held within DNS SRV/TXT records, so I don't
see this being a problem in any case.


> *Last Call: XEP-0412 (XMPP Compliance Suites 2019)* -
> https://xmpp.org/extensions/xep-0412.html
> Dave: [pending]
> Georg: +1
> Jonas: +1
> Kev: +1
> Link: +1
>
> +1


> *Last Call: XEP-0292 (vCard4 Over XMPP)* -
> https://xmpp.org/extensions/xep-0292.html
> Dave: [pending]
> Georg: +1 (no need to block an LC)
> Jonas: +1
> Kev: +0 (don't think this is ready to advance, but no objection to LC)
> Link: +1
>
> +1


> *Last Call: XEP-0335 (JSON Containers)* -
> https://xmpp.org/extensions/xep-0335.html
> Dave: [pending]
> Georg: +1
> Jonas: +1
> Kev: +1
> Link: +1
>

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

Re: [Standards] Summit Agendum: Message IDs

[Dave Cridland]

Let's assume, for a moment, that we do not wish to attempt to solve
deliberate duplication of ids, and instead assume that any duplication is a
bug.

Let's further assume that "if only" the @id attribute of a stanza were both
always present, and globally unique, it'd work.

What if:

a) Clients can make some assertion that they will generate a
globally-unique @id on stanzas.

b) Servers can also advertise assertions that they, too, deal with globally
unique stanzas identifiers. If a connected client fails to make the
assertion, the server either:

i) Injects a stanza-id of its own, or:

ii) Changing the @id and encodes the original @id within it, somehow. (They
could use any scheme for that, and might want to consider something that's
difficult or impossible to emulate).

c) MUC services (and similar broadcasters) advertise a "stable identifier"
thing. Since @id's are now globally unique, they can be passed through -
but a MUC service faced with a server that isn't asserting the Thing can
choose to override the @id.

d) If a server is doing the id thing, and a client asserts same, and fails
to include an @id on any stanza, that stanza is bounced.

Is that enough? And if not, can it be refined to the point it works?

On Tue, 29 Jan 2019 at 15:31, Georg Lukas  wrote:

> Hi together,
>
> I've added a "Message IDs and References" agendum to the Summit
> discussion agenda. As I probably won't be able to attend, I wanted to
> elaborate what exactly the problems I'd like to see solved are, and
> maybe even ignite a bit of on-list discussion pre-Summit.
>
> We currently have three ways to identify a message:
>
> - the semi-optional semi-unique stanza @id
>   
>
> - the  introduced as a work-around for @id being rewritten
>   by MUCs and not being unique in a guaranteed, observable from the
>   outside, way 
>
> - the  injected by MAM and MUC (I count the MIX generated
>   @id into this category as well)
>   
>
> Furthermore, we have different use cases for referencing a message:
>
> - own message reflection matching in a MUC (scoped by your participant
>   JID, might be needed over reconnects under bad timing)
>
> - XEP-0184 Receipts (scoped by the sender JID, except for MUCs where it
>   is NOT RECOMMENDED but might still be requested and sent, persistent
>   over connections)
>
> - XEP-0333 Markers (no explicit scoping defined, but probably implicitly
>   scoped by the bare JID, so a MUC participant can send markable
>   messages with duplicate @id to confuse other participants)
>
> - XEP-0372 References ("TODO: URI scheme for messages", probably
>   requires scoping by bare JID or participant JID and sufficient
>   persistence)
>
> - Emoji Reactions (same requirements as 0372)
>   
>
> - XEP-0367 Message Attaching (scoped by MUC/bare JID, with persistence,
>   has the most sophisticated @id usage rules)
>   
>
> - Threading (this has largely unsolved UX and is widely ignored)
>
> Out of these, XEP-0367 has the most robust and most advanced rules, and
> those are probably the best foundation for a universal reference-id
> specification that could be put into all of the other XEPs mentioned
> above.
>
> However, there are multiple issues I see with those rules:
>
> - they are rather complex
>
> - they require 0359+MAM support in a MUC (and 0359 in the client)
>
> - they don't cover MIX yet (but the change should be trivial)
>
> - you can not reference a message that wasn't yet reflected(*)
>
> (*) I see this as problematic in offline/high-latency situations: if you
> want to send a message and a reference to it back-to-back, you need to
> delay the second one until the first one was reflected. If you want to
> prepare a message and a reference-message while offline (writing a
> message for later delivery is a useful feature in a mobile client), you
> need to keep a local reference (based on @id presumably), then to not
> send the second message until the first one is reflected, and then to
> rewrite the reference to the server-mandated one.
>
> The last one is a nasty, but not unsolvable problem. Maybe somebody can
> come up with a more elegant solution that is not prone to the problem of
> attacker-sends-id-duplicates, in which case I'd like to make this set of
> rules into the official way to reference messages (maybe it should be
> put into an Informational XEP and referenced from all the others?)
>
>
>
> Georg
> --
> || http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
> || gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
> || Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
> ++ IRCnet OFTC OPN ||_||
> 

Re: [Standards] SASL MTI

[Dave Cridland]

On Fri, 25 Jan 2019 at 12:08, Evgeny  wrote:

> On Fri, Jan 25, 2019 at 1:45 PM, Dave Cridland 
> wrote:
> > I'm hearing "no", here - which is fine - but I do have a design for
> > enforced password changes and password resets, too. The former is
> > built around SASL2 (XEP-0388) and was actually one of the original
> > design goals. Password resets we built at Surevine as a SASL
> > mechanism (which we used with SASL2, but it'd work with the existing
> > SASL profile in RFC 6120 as well).
>
> 1) I already criticized SASL2 back then for unnecessary complexity.
>

Yes, although I admit that when everything is criticised for unnecessary
complexity it can become quite difficult to figure out what's a genuine
complaint. This isn't just you, by the way - literally everything we try to
do gets criticised on that basis.

I found it relatively straightforward to implement, and moreover, adjusted
the spec to match that.


> 2) SASL2 still exists on the paper only without wide adoption.
>

Certainly it doesn't have wide adoption, but it has some.


> 3) I'm not sure every operator will be fine with the solution to force
> users changing passwords. I use a lot of services and I'm having hard
> time remembering any service doing this so far. Should we ignore this
> common practice?
>

I'm merely offering suggestions. I'm in full agreement that enforcing
password changes is not a solution for many use cases.


> 4) What about situation with -PLUS variants? What's the answer to above
> Daniel's question related to TLSv1.3? Will we have problems with
> TLSv1.4?
>

-PLUS variants are problematic on a number of environments because the
necessary data isn't available.

However, where available, tls-unique as written is *still* significantly
better than no -PLUS at all, and requires a substantial effort to attack.


> 4) I actually described several problems with SCRAM, and I did that for
> a reason, but seems like only those related to SHA upgrades are
> addressed (on the paper only BTW). What about potential downgrade
> attacks (including false positives)? Is it clear for all developers?
> For example, for me it's not that obvious what exactly to treat as a
> downgrade attack. What about interop with other services? What about
> performance degradation when SASL PLAIN is used with SCRAM'ed
> passwords? We already have "avalanche problem" caused by server
> restarts, and SASL PLAIN + SCRAM'ed passwords only worsen it. Also, if
> an attacker harvests enough JIDs it may successfully perform DDoS
> against the server forcing it to compute HMACs at a high rate.
>
>
I'm not clear what you mean by "potential downgrade attacks (including
false positives)".

I think Sam addresses your comments about performance in much the same way
I would.


> >> I personally prefer:
> >> 1) MUST for EXTERNAL and PLAIN
> >> 2) SHOULD for SCRAM-SHA-X-Y (I'd prefer not to use SCRAM at all
> >>given all the problems I have described in another thread)
> >
> > I'm hearing "yes" here, however.
> >
> > Would you be interested in updating the MTI?
>
> No. I don't have neither time nor desire to fiddle with IETF
> bureaucracy. Furthermore, that's not me who put SCRAM in the RFC. Also,
> we require SCRAM-SHA1-PLUS for years now, but still not every server or
> client implement it (typically only SCRAM-SHA1 is implemented). And
> seems like nobody gives a f*** for the RFC requirement. For me simple
> wiki page with clarifications and provided solutions is enough.
>
> ___
> 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] SASL MTI

[Dave Cridland]

On Thu, 24 Jan 2019 at 20:03, Evgeny  wrote:

> On Thu, Jan 24, 2019 at 9:15 PM, Dave Cridland 
> wrote:
> > XMPP-Grid (that draft) essentially says both servers and clients MUST
> > implement EXTERNAL, SCRAM-SHA1, SCRAM-SHA1-PLUS, SCRAM-SHA-256, and
> > SCRAM-SHA-256-PLUS.
> >
> > Is there any interest in updating our MTI?
>
> How can we require SHA-256 when we don't have any way to upgrade
> existing deployments from SHA-1? Leaving the burden to the operators
> again, because this is out of scope of XSF? :)
> Some already suggested "solving" this by forcing password
> renewal, but we don't have any mechanisms to do this in XMPP.
>
>
I'm hearing "no", here - which is fine - but I do have a design for
enforced password changes and password resets, too. The former is built
around SASL2 (XEP-0388) and was actually one of the original design goals.
Password resets we built at Surevine as a SASL mechanism (which we used
with SASL2, but it'd work with the existing SASL profile in RFC 6120 as
well).

I'm going to assume you'd like me to document these?

An issue here is that it's impossible under both RFC 6120's SASL profile
and XEP-0388 to have a mechanism that'll only work for some users - that
is, you can't list SCRAM-SHA-256* only for users who have credentials
stored. This has been a matter of deliberate design fairly consistently -
otherwise it's possible to test if a user exists or not, which is generally
considered bad practise.

I personally prefer:
> 1) MUST for EXTERNAL and PLAIN
> 2) SHOULD for SCRAM-SHA-X-Y (I'd prefer not to use SCRAM at all
>given all the problems I have described in another thread)


I'm hearing "yes" here, however.

Would you be interested in updating the MTI?

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

[Standards] SASL MTI

[Dave Cridland]

There's an ongoing discussion about
https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ - a document
currently about to be voted on by the IESG - which includes a slightly
different set of SASL mechanisms as Mandatory To Implement.

Our current MTI is from RFC 6120, and can be summarized as:

Servers MUST implement EXTERNAL, SCRAM-SHA1 and SCRAM-SHA1-PLUS.
Client MUST implement SCRAM-SHA1 and SCRAM-SHA1-PLUS, and SHOULD implement
EXTERNAL and PLAIN (the latter so servers can support some pre-existing
authentication systems).

XMPP-Grid (that draft) essentially says both servers and clients MUST
implement EXTERNAL, SCRAM-SHA1, SCRAM-SHA1-PLUS, SCRAM-SHA-256, and
SCRAM-SHA-256-PLUS.

Is there any interest in updating our MTI?

I would imagine any work would need to be done in the IETF, in conformance
with their "Note Well".

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

[Standards] Council Agenda 2019-01-09

[Dave Cridland]

The XMPP Council will be holding it's regular meeting today (Wednesday) at
1600 UTC. The agenda is collated from (in order of reliability):
* Github pull requests and issues marked "Needs Council":
https://github.com/xsf/xeps/labels/Needs%20Council
* Random mails from Standards List
* Random suggestions directly to me

I (try to) send out the final agenda about 24 hours in advance.

Agenda as follows:

1) Roll Call

2) Agenda Bashing

a) Highly likely I've missed something. Feel free to "pre-bash" if I have,
by replying to this.

3) Items for voting:

a) #733: Issue Last Call for XEP-0355

Namespace Delegation

https://xmpp.org/extensions/xep-0355.html

b) #743:

XEP-0156: Add implementation notes suggesting CORS

https://github.com/xsf/xeps/pull/743

c) Issue Last Call for XEP-0412

XMPP Compliance Suites 2019

https://xmpp.org/extensions/xep-0412.html

d) Issue Last Call for XEP-0292

vCard4 Over XMPP

https://xmpp.org/extensions/xep-0292.html

4) Outstanding Votes

5) Next Meeting

6) AOB

7) Close

Note that I'm aiming for 30 minutes.

Meetings are normally held every Wednesday at 1600 UTC in the
xmpp:coun...@muc.xmpp.org?join
 chatroom.
Meetings are open, and anyone
(XSF Member or not) may attend, though only XMPP Council members may
vote. Relevant comments from the floor are welcomed.

Thanks,

Dave.
(As Council Chair).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Tidying Deferred

[Dave Cridland]

On Thu, 17 Jan 2019 at 17:41, Ненахов Андрей 
wrote:

> чт, 17 янв. 2019 г. в 15:38, Ralph Meijer :
> > 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.
>
> Yes, so far this process has led XMPP to a great success, with jabber
> being used as a primary communication protocol by a significant
> portion of internet users.
>

XMPP has always struggled with being a primary communications method for a
significant portion of internet users. On the other hand, it is widely used
within a broad selection of niche areas (frustratingly, to me, many of
these are not federated).

However, our greatest successes haven't correlated with standards which
were brought to the XSF having already been implemented - they have
occurred where multiple implementors collaborate, openly, from an early
stage.

Examples of the former include Jingle, where we still struggle with any
kind of interoperability.
Example of the latter include MUC.

I think early implementation is very important - which is why I argued we
should remove barriers to it such as the old "tmp" namespace strategy, for
example, and I personally weight implementation very highly in advancement,
even when it's not strictly required. But the risk of imposing a rule that
says people must implement first, and standardise later, is that those same
people will expect to be able to have their specifications rubber-stamped
through the process.

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

Re: [Standards] Tidying Deferred

[Dave Cridland]

On Thu, 17 Jan 2019 at 10:38, Ralph Meijer  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.

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

Re: [Standards] Tidying Deferred

[Dave Cridland]

On Thu, 17 Jan 2019 at 09: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.
>
>
I'm highly against this. Our process is actually very clear on this - while
we encourage implementation throughout, we do not require it until Final -
not even Draft has an absolute requirement.


> Also, XEP-0333 Chat Markers should not belong to deferred. It is
> widely used in XMPP clients.
>
>
Is that a request to Last Call it? Happy to put that on the Council agenda
if you like.


> --
> Ненахов Андрей
> Директор ООО "Редсолюшн" (Челябинск)
> (351) 750-50-04
> http://www.redsolution.ru
> ___
> 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] Tidying Deferred

[Dave Cridland]

On Wed, 16 Jan 2019 at 20:48, Tedd Sterr  wrote:

> I think the first issue is to decide the actual purpose Deferred is meant
> to be serving - according to XEP-0001, that is essentially "was
> experimental, but has had no attention for 12 months;" I don't think anyone
> has a problem with that. The problem comes from nothing happening beyond
> this point; so there they sit: maybe they'll be resurrected, maybe they'll
> just rot. So now we have a huge pile of Deferred XEPs, some of which were
> temporarily left due to the author being otherwise busy, some of those
> subsequently fell off the radar, and others that were intentionally
> abandoned - with little way to tell the difference. Some people are content
> with this ("if the author cares enough, they can always pick it up again");
> others would like to at least remove the entirely-abandoned so it's easier
> to see what's actually relevant.
>
> Jonas's idea is to review one each week, but given that there are
> currently 177 Deferred XEPs, that would take 3.5 years (assuming 50 per
> year) and further months for the additional pile deferred since. Of course,
> doing several per week would be too much work, and a waste of effort that
> could be put to better use.
>
> My own preference would be for Deferred to represent a state of "good
> idea; still needs more work; contributions welcome" - which it arguably
> already does, but it also includes many that should legitimately be
> obsoleted (not that it's worth anyone's time to figure out by what),
> reducing the signal-noise ratio.
>
> For interest:
>  - 177 Deferred: 154 Standards, 19 Informational, 3 Historical, 1 SIG
>  - eldest: 16.5 years
>  - oldest 25%: 10.7+ years
>  - oldest 50%:  6.5+ years
>  - oldest 75%:  1.3+ years
>
> As a quick first pass, maybe we could take the oldest 25% (44 XEPs),
> community gives them a quick look over to decide whether they could ever
> have any possible minuscule interest, if so they make it known (no
> justification necessary, just the XEP numbers), and then after some
> appropriate period we say that the remainder can safely be rejected. I
> suspect the vast majority of these can be swept away as being no longer
> appropriate/relevant/interesting.
>


Thanks for this. As I said in the Council meeting yeserday, I really don't
care very much about Deferred XEPs which could be moved to a dead state. I
do, however, care about finding the XEPs which should be advanced (or just
revived). I could be persuaded that clearing out the dead wood might make
it easier to find the hidden gems.

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 Council do this unilaterally (if, of course,
we allowed this in XEP-0001)?

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
Council has to agree to put something into Last Call, anyone can request
that of the Council, as (in my guise as Council Chair) I'm happy to have
the Council vote on any Last Call as a general rule.

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

Re: [Standards] [XEP-0335] Request for Last Call

[Dave Cridland]

On Fri, 11 Jan 2019 at 13:10, Matthew Wild  wrote:

> Dear Council,
>
> I would like to request that XEP-0335 be considered for Last Call. It
> is a fairly small XEP that has implementations in the wild and
> deserves to advance in my opinion.
>

Thanks, I've added this as #733: https://github.com/xsf/xeps/issues/733

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

Re: [Standards] XEP-0410: MUC Self-Ping - Feature needed?

[Dave Cridland]

On Tue, 8 Jan 2019 at 18:23, Florian Schmaus  wrote:

> On 08.01.19 17:00, Jonas Schäfer wrote:
> > On Dienstag, 8. Januar 2019 16:50:43 CET Georg Lukas wrote:
> >> * Jonas Schäfer  [2018-12-14 16:18]:
> >>> I think adding a distinct feature is a good idea. Even if clients don’t
> >>> act on it (I’m not sure what they could (not) do by knowing that the
> >>> server does (not) support it), it is useful to meter the deployment in
> >>> the wild.
> >>>
> >>> I suggest to use `
> http://jabber.org/protocol/muc#self-ping-optimisation`
> .
> >>
> >> That's perfectly fine with me. Should this go into the MUC domain
> >> disco#info, the MUC room disco#info or both?
> >
> > MUC room is best, I think.
>
> I would lean towards advertising it at the MUC service address. It is
> essentially a MUC service implementation feature and hence I doubt that
> we ever have the case that this feature is only enabled for a subset of
> rooms.
>

For sure, but the feature itself pertains to the room. Client
implementations need to look at room features anyway for MAM etc - it might
be worth having a caps-a-like for MUC, though.


>
> - Florian
>
> ___
> 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-0410: MUC Self-Ping - Feature needed?

[Dave Cridland]

Yes, I think a distinct feature is needed, and that feature should indicate
support for the optimisation in §3.3.

On Fri, 14 Dec 2018 at 15:01, Georg Lukas  wrote:

> Hello,
>
> I'd like to ask for a Last Call for XEP-0410. It's got implemented in
> two clients and two servers so far:
>
> - poezio 0.12
> - yaxim 0.9.3
> - ejabberd 18.12
> - prosody 0.11
>
> One question that was brought up recently is whether a MUC service
> should advertise support for the self-ping optimization
> , and
> whether  should be used for that.
>
> As this is only an optimization that doesn't change the protocol, I
> don't see an urgent need to advertise it, but maybe there are use cases
> I haven't anticipated. If this is wished for, it should have its own
> feature tag ("optimizes self-pings") and not use urn:xmpp:ping
> ("supports XEP-0199 pings") IMO. Opinions?
>
>
> Georg
> --
> || http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
> || gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
> || Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
> ++ IRCnet OFTC OPN ||_||
> ___
> 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] LAST CALL: XEP-0410 (MUC Self-Ping (Schrödinger's Chat))

[Dave Cridland]

On Tue, 8 Jan 2019 at 16:55, Jonas Schäfer  wrote:

> This message constitutes notice of a Last Call for comments on
> XEP-0410.
>
> Title: MUC Self-Ping (Schrödinger's Chat)
> Abstract:
> This protocol extension for XEP-0045 Multi User Chat allows clients to
> check whether they are still joined to a chatroom.
>
> URL: https://xmpp.org/extensions/xep-0410.html
>
> This Last Call begins today and shall end at the close of business on
> 2019-01-22.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
Yes, I think the problem statement is valid.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
>
Somewhat - I think there are existing concerns with whether a feature
should be advertised, and §3.3 made mandatory for this feature.


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
Yes, I'll probably knock it out when it has a feature.


> 4. Do you have any security concerns related to this specification?
>
>
None.


> 5. Is the specification accurate and clearly written?
>
>
Several sections are left as the template REQUIRED.


> Your feedback is appreciated!
> ___
> 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] LAST CALL: XEP-0280 (Message Carbons)

[Dave Cridland]

On Tue, 8 Jan 2019 at 16:54, Jonas Schäfer  wrote:

> This message constitutes notice of a Last Call for comments on
> XEP-0280.
>
> Title: Message Carbons
> Abstract:
> In order to keep all IM clients for a user engaged in a conversation,
> outbound messages are carbon-copied to all interested resources.
>
> URL: https://xmpp.org/extensions/xep-0280.html
>
> This Last Call begins today and shall end at the close of business on
> 2019-01-22.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
Yes, it fills an important gap. Perhaps not the way I'd ideally like it to
be filled, but a good specification is better than the dream of a perfect
one.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
>
It seems to work well to alleviate the problem.


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
I have implemented it in various cases.


> 4. Do you have any security concerns related to this specification?
>
>
No outstanding concerns.


> 5. Is the specification accurate and clearly written?
>
>
Yes, it was straightforward to work with.


> Your feedback is appreciated!
> ___
> 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] Histroy tranfer idea

[Dave Cridland]

On Wed, 2 Jan 2019 at 17:07, Evgeny  wrote:

> On Wed, Jan 2, 2019 at 7:49 PM, Dave Cridland  wrote:
> > Out of curiosity, do we know if the cryptographic properties involved
> > in sending a known set of plaintext about like that stack up?
>
> I wonder how everyone is fixated on crypto part while the hardest
> part is messages replication itself: in the described scenario we
> introduce several replicas of messages - client devices (which can
> be many) and a server. This quickly rises several questions related
> to a replication in distributed systems:
> 1) how to perform deduplication
> also, if MAM is disabled on the server:
> 2) how to maintain message casuality (among client devices)
> 3) how to maintain replica merges after partitions (between client
> devices)
>
> While I like the idea of messages replication between user devices,
> I think the implementation will be too complex for a regular XMPP
> client developer
> even if we write down all this in a XEP.
>

Yes, I think I agree with these points, too.

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

Re: [Standards] Histroy tranfer idea

[Dave Cridland]

You'd be most welcome to write this down and submit it as a XEP - it's
really not as hard as it sounds, and you don't need to worry about too much
detail at this stage.

Out of curiosity, do we know if the cryptographic properties involved in
sending a known set of plaintext about like that stack up?


On Wed, 2 Jan 2019 at 15:47, j.r  wrote:

> Hello list,
>
> today I had an idea for a way to transfer history from old clients to
> newly added ones:
>
> If a new client is added to an account it request to the other clients
> if they could send the history over. If the other client somehow trust
> the new client (e.g. with a accept dialogue) it encrypts all messages
> for the OMEMO Key of the new Client and sends them to it. The new client
> will decrypt it and save it to his database.
>
> It would be an easy way for not very technical users to switch devices
> or so.
>
> Now I have two questions: what do you think about this in general? And
> if you like the idea is there someone that could help me to write it
> down as an XEP? (Because I've never written an XEP before and that idea
> is somehow complex)
>
> Thanks for you attention
> j.r
> ___
> 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] XMPP Council Minutes 2018-12-19

[Dave Cridland]

Hi folks,

There were two heavy chunks of "Process" in this meeting. Surprisingly, I
hate process - as anyone I've worked with can attest - but I'm usually the
one defending it, so here I go again.

The reason we have a process is not to make our lives more difficult, but
to make everyone's lives - particularly participants' - easier. With a
typical open source project on Github, there's so much tooling around the
process people often think it doesn't exist, but there usually is some
process. A contributor comes along and suggests a change, it's reviewed by
the maintainers, and if approved, it's merged. If a new contributor turns
up and sees a project hosted on Github, they know roughly how things are
going to work.

That's kind of what we have, except the "people who merge", and the "people
who review" are different - they're the "XMPP Extensions Editor" and the
"XMPP Council" respectively a lot of the time - for experimental XEPs, or
process XEPs, it's different. When it's different is covered by XEP-0001,
and what changes can be approved is also covered by XEP-0001. That is, in a
nutshell, our process.

But the idea is that a new participant in our standards ought to be able to
read XEP-0001, and from that gain a set of expectations on how to
contribute to documents and what will happen. Moreover, if Council (for
example) do not follow this, they can be called out on it. Every now and
then, people do try to insist that the XSF does something unusual with
their favourite document, for reasons ranging from commercial
considerations to deciding they want the document moved to another
Standards Development Org that will do what they want. Having a defined
process means both that the Council has a simple defence here, and that all
the other participants - and that's you, if you're reading this - aren't
going to be taken by surprise.

That is not to say that our process is either perfect, nor immutable. I
find it as irritating as anyone else when we find ourselves trapped by the
process, or having to jump through hoops in order to satisfy it. Process
should not be a stick with which to beat people. Our process should simply
describe what we do - so sticking to it should be easy. If we can improve
it, we should do so, and anyone - XSF Member or not - can suggest process
improvements (such as simplifications), and ask the Board to approve them.

So, "We'd like to move a XEP from Deferred to Obsolete" is not a suggestion
that is intrinsically wrong, but one we cannot do. But if (in this case)
Emmanuel wants this to be possible, it's possible to change things so we
can. We've changed it recently for largely similar things.

On the other hand, Jonas's slip-up can be resolved. In this case, Council
were generally not worried, and offered a suggestion to Board. Board
rejected it, and have insisted on a different resolution. And I'm delighted
with the way this has worked out, even though Board disagreed with what
Council (including myself) wanted to do.

The real test of openness, fairness, and transparency in an organisation is
when things go wrong. In this case - and many thanks to Jonas for providing
the opportunity - I'm very comfortable that we passed that test.

Dave.

On Thu, 20 Dec 2018 at 20:27, Tedd Sterr  wrote:

> http://logs.xmpp.org/council/2018-12-19/#16:00:41
>
> *1) Who's Here?*
> Present: Jonas, Georg, Dave, Link
> Fashionably late: Kev
>
> Dave asks if there is anything new to vote on - Jonas points to PR #727 (
> https://github.com/xsf/xeps/pull/727); Georg would like to ask for an LC
> on XEP-0410.
>
> [PR #727 moves three XEPs from Deferred to Obsolete, as they were deferred
> long ago and appear to be no longer useful.]
> Jonas thinks XEP-0008 should be made Active (it's historical), and
> XEP-0051 can be obsoleted with a reference to the  stream
> error, but has no idea about XEP-0038.
> Dave doesn't think XEPs can be moved from Deferred to Obsolete; Jonas
> concurs.
> Link suggests skipping a few states in the path to Obsolete for XEPs that
> will obviously no longer be needed; Dave says it would be possible to do:
> Deferred → Experimental → Proposed → Rejected, with a well-placed Last Call.
> Dave asks what Link is actually trying to achieve, and why Deferred is not
> good enough - Link would like to sort the deferred XEPs into "no longer
> needed" and "should be LC-ed"; Jonas likes that plan.
> Link would like to eventually deprecate the Obsolete state; Dave says the
> point of the state is to de-clutter Experimental. Jonas suggests focusing
> more on saving those that might be useful.
> Dave concludes that current process doesn't allow for this, and is
> therefore not keen on voting on it. Link queries escalating the matter to
> Board - Dave suggests putting it to The List.
>
> *2) Last Call: XEP-0410 (MUC Self-Ping (Schrödinger's Chat))* -
> https://xmpp.org/extensions/xep-0410.html
> Georg: +1 (obviously)
> Link: +1 (been testing an implementation and it did improve things greatly
> 

Re: [Standards] NEW: XEP-0412 (XMPP Compliance Suites 2019)

[Dave Cridland]

Hi Jonas,

Thanks for sorting this out, and my apologies for the formal process hoops
to jump through.

I'm amazed this has never happened before, actually.

Dave.

On Thu, 20 Dec 2018 at 16:13, Jonas Schäfer  wrote:

> Hi list,
>
> 
> I published this specification (XEP-0412) ahead of time. The vote of
> council
> (which I am embarrassingly part of) has not yet completed.
>
> While the stance of Council (including the member who hasn’t voted yet and
> me)
> on this matter was to wait it out and deal with the issue of retraction
> should
> the vote be a -1, the Board has decided to prevent to set a precedent by
> the
> premature publication, which could be used by the Editor to exert pressure
> on
> the not-yet-voted Council members.
>
> I personally fully support the decision of the Board.
>
> I understand the delicacy of the situation especially since in this play,
> I’m
> both the Editor *and* the Author of the specification; I do not want to be
> seen as someone who would abuse any role like that, so I’m happy to
> execute
> the Board’s ruling.
>
> I’d also like to sincerely apologize especially to Kev whose vote I have
> forgotten (actually I was 100% sure that everyone had voted, and only
> while
> checking results for other votes I came across the "on list" from Kev :()
> and
> to the community for the extra noise and possible temporary confusion and
> misguidance due to the published compliance suites you had to endure. I’d
> also
> like to apologize for not bringing this matter up to Board immediately.
>
> The specification has been un-published and replaced with a tombstone XEP
> (the
> build is still in progress; the website will thus be updated shortly). It
> will
> stay a tombstone should Kevin decide to vote -1, and it will be replaced
> with
> the actual XEP again should Kevin decide to vote 1 or 0.
> 
>
> kind regards,
> Jonas___
> 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
___

[Standards] XEP-0288 - Bidi - Maybe CFE?

[Dave Cridland]

Hi folks,

I'm thinking of asking the Editor to issue a Call For Experience on
XEP-0288.

I would do so now, but I'm not entirely sure who actually implements it.

So, who does implement it? (And is your implementation open source)?

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

Re: [Standards] Proposed XMPP Extension: Simple Buttons

[Dave Cridland]

Looks like a problem worth solving, but note below.

I'd prefer - non blockingly - the following:

* A click element. I feel that having an id and a click is superior given
the ambiguity of a text string.
* The examples should be changed to include a Big Red Button. I think the
worthwhile gag would be funnier this way.

Blocking:

* How does this relate, if at all, to Forms?

Dave.

On Thu, 6 Dec 2018, 19:45 Jonas Schäfer  The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Simple Buttons
> Abstract:
> This specification provides a way to send simple buttons.
>
> URL: https://xmpp.org/extensions/inbox/buttons.html
>
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> 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] LAST CALL: XEP-0359 (Unique and Stable Stanza IDs)

[Dave Cridland]

On Mon, 26 Nov 2018 at 12:09, Ненахов Андрей 
wrote:

> пн, 26 нояб. 2018 г. в 17:02, Dave Cridland :
> >> Yes, so? Anyway we're discussing a XEP for Unique and Stable Stanza
> >> ID, and we like it as it currently is, precisely because we can count
> >> on origin-id being unique.
> > Why do you think that?
>
> Because it's written in XEP-0359. If a client conforms to it, it is
> kinda likely that origin-ids will be unique within scope. If not,
> well, our server will not break, but behavior will be unpredictable.
> But it's user's problems if he uses a client with broken
> implementation of unique IDs, no?
>
>
XEP-0359: "Thus the IDs defined in this extension MUST be unique and stable
within the scope of the generating XMPP entity."

RFC 6120: "It is up to the originating entity whether the value of the 'id'
   attribute is unique only within its current stream or unique
   globally."

Really, XEP-0359 provides very little in terms of a stronger requirement
for other entities to give you unique identifiers, and I thought it was
mostly about being able to add in your own identifiers on the basis that
other entities couldn't be relied upon to be unique.

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

Re: [Standards] LAST CALL: XEP-0359 (Unique and Stable Stanza IDs)

[Dave Cridland]

On Mon, 26 Nov 2018 at 11:01, Ненахов Андрей 
wrote:

> пн, 26 нояб. 2018 г. в 15:12, Dave Cridland :
> > But surely if a client connects and doesn't send an origin-id, you know
> the message id might not be unique?
>
> Yes, so? Anyway we're discussing a XEP for Unique and Stable Stanza
> ID, and we like it as it currently is, precisely because we can count
> on origin-id being unique.
>

Why do you think that?

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

Re: [Standards] LAST CALL: XEP-0359 (Unique and Stable Stanza IDs)

[Dave Cridland]

On Mon, 26 Nov 2018 at 10:00, Ненахов Андрей 
wrote:

> пн, 26 нояб. 2018 г. в 14:48, Georg Lukas :
> > If your client is using them to associate message reflections, I am sure
> > you can make them unique client-side, right? So just because it's not
> > REQUIRED is not an argument to make it work?
>
> Our client can make them unique, no problem. But if our server is
> connected by a client that does not make them unique, it'll likely
> function improperly. (We've seen clients that just counted message ids
> from 1 on every restart. Don't recall which one though, was a long
> time ago) So we preferred to stick with a XEP that explicitly states
> what we need.
>
>
But surely if a client connects and doesn't send an origin-id, you know the
message id might not be unique?

Dave.


> --
> Ненахов Андрей
> Директор ООО "Редсолюшн" (Челябинск)
> (351) 750-50-04
> http://www.redsolution.ru
> ___
> 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] XMPP Council Minutes 2018-11-14

[Dave Cridland]

Hi all,

Sorry about last Wednesday, unfortunately I've had a bit of a family crisis
which needed a lot of attention - it should now be in hand, but my head
hasn't really had the space to think until now.

On Thu, 15 Nov 2018 at 19:40, Tedd Sterr  wrote:

> http://logs.xmpp.org/council/2018-11-14/#16:01:26
>
> Kev rounds up the troops.
>
> *1) Roll call*
> Present: Georg, Kev, Sam
> Apologies: Daniel
> Missing, presumed alive: Dave
>
> *2) Agenda*
> Kev takes one look at the long list of potential items and proposes
> putting everything off until next week, under the mistaken belief there
> will be an extra week to work with - he's soon corrected.
> Georg and Sam would prefer to get the voting started now and have a week
> for on-list discussion - Kev gives in to popular opinion.
>
> *3) Advance XEP-0357 (Push Notifications) to DRAFT* -
> https://xmpp.org/extensions/xep-0357.html
> Kev: [on-list]
> Sam: [on-list] (don't really have the necessary background knowledge for a
> good opinion)
> Georg: -1 (high priority topic hasn't been addressed; but really liked the
> stripped stanza proposal)
> Daniel: [pending]
> Dave: [pending]
>
> Kev is very much in favour of allowing pushing through the real data.
> Georg thinks the current XEP is much better than it was half a year ago,
> but the feedback from August hasn't been addressed.
> Kev thinks privacy does need to be supported, but it's useful to allow
> users/deployments to decide the trade-off between utility and privacy;
> Georg says a tri-state of none/stripped/full would make that possible; Sam
> thinks that seems over-complicated, but supports allowing data.
> Kev admits some responsibility for 0357, and should put time in, but a
> time-machine might be required.
>
>
I believe this is awaiting a bit of processing of feedback - so I'm a -1 on
advancing it right now.


> *4) Advance XEP-0359 (Unique and Stable Stanza IDs) to DRAFT* -
> https://xmpp.org/extensions/xep-0359.html
> Georg thinks the current status quo of hard-coding "you have a new
> message" into the server module is non-ideal; has submitted some feedback
> and would like to see it addressed, but won't block on that basis.
>
>
I don't quite understand that - is the new message thing to do with '357?


> Georg: +0 (+1 if above feedback is properly addressed)
> Kev: [on-list]
> Sam: [on-list]
> Daniel: [pending]
> Dave: [pending]
>
>
+1

I don't particularly like the stanza-id concept, but I'll grudgingly admit
it's needed. I'm a little concerned that the structure means that there's
be lots of elements in the message under the same namespace which all need
an explicit namespace declaration - that said, the alternative would be
harder for processors to slip into stanzas on the way past, so perhaps this
is the lesser of two evils.


> *5) PR #692 - XEP-0060: correct "entity" to ""* -
> https://github.com/xsf/xeps/pull/692
> Kev: [on-list]
> Sam: +0
> Georg: [on-list]
> Daniel: [pending]
> Dave: [pending]
>
>
+1


> *6) PR #693 - XEP-0060: Remove unused 'node' attribute on pubsub#event
> item* - https://github.com/xsf/xeps/pull/693
> Kev: [on-list]
> Georg: [on-list]
> Sam: +0 (not confident enough with pub-sub to review it, no matter how
> many times I re-read it)
> Daniel: [pending]
> Dave: [pending]
>
> Georg thinks this meeting is so productive!
>
>
+1


> *7) PR #715 - XEP-0045: Add missing disco#info feature to example 4, 9, 78
> and 218* - https://github.com/xsf/xeps/pull/715
> Kev: [on-list]
> Georg: [on-list]
> Sam: +1
> Daniel: [pending]
> Dave: [pending]
>
>
+0 - this is reasonable, but I don't think it matters that much. See below.


> *8) PR #716 - XEP-0030: Clarify 'disco#info' feature in 'disco#info'
> responses* - https://github.com/xsf/xeps/pull/716
> Kev: [on-list]
> Sam: -1
> Georg: [on-list]
> Daniel: [pending]
> Dave: [pending]
>
> Sam agrees that it's weird to always include 'disco#info' when it's
> obviously supported, but doesn't see the need to modify a Final XEP and add
> optional behaviour, and recommends just following the standard as written.
> Jonas thinks that's the most sensible word on the subject so far.
> Jonas could ensure that the feature is present in every relevant example
> in the XEP, if Council so wishes.
> Kev isn't keen on making non-vital changes to XEP-0030. Sam doesn't think
> leaving it as-is will cause anything to break.
> Georg isn't sure it's needed in all examples in all XEPs, and would rather
> add a note in 0030 that the feature may not be present in examples but must
> still be implemented; Sam thinks that sounds reasonable. Georg and Sam
> agree this would be an editorial change, and would be happy for Editors to
> just change it. Jonas requests wording - Sam provides "Note that this is
> sometimes omitted in examples in the XEP series"; Georg amends that to
> "Note that the disco#info feature is …"
>
>
+1 - If we say that disco#info responses MUST include the disco#info
feature, we have a MUST that has no impact on interoperability, and 

Re: [Standards] XMPP Council Minutes 2010-10-10

[Dave Cridland]

On Sat, 13 Oct 2018, 19:10 Tedd Sterr,  wrote:

> > *2) PR #706 - Update BCP 14 language to comply with RFC 8174* -
> https://github.com/xsf/xeps/pull/706
>
> I have to wonder whether "an implementation must" could mean anything
> different from "an implementation MUST" -- how else could it be
> interpreted? Would 'must' mean it's actually not mandatory, but 'MUST'
> does? I've always considered the upper-casing as little more than
> highlighting/emphasis.
>

Three things:

* Firstly, the easy bit - you must have considered that people may use
ordinary English words in their ordinary English meanings. So while one
can't say "an implementation must X" and mean anything but "X is
mandatory", should other phrasings be used the RFC 2119 interpretations may
not apply. This is particularly important with negations and "should",
which should always be considered a grey area in English usage.

* Secondly, RFC 2119 language is indicative of a requirement for
"interoperation or to limit behavior[sic] which has the potential for
causing harm". You can't say "An implementation MUST back this data onto a
SQL database", for example.

* Equally, not all interoperability requirements are spelt out (or indeed
should be spelt out) as RFC 2119 language. I personally find it easier to
write (and read) "The maximum number of items returned is ten" than the
more tortuous "Implementions MUST NOT return more than 10 items" - though I
appreciate that non-native English speakers often prefer the second.

This does mean that "an implementation must X" doesn't automatically mean
that an implementation has an absolute requirement to do X due to
interoperability or to limit behaviour which has the potential to cause
harm - even though the specification is saying that to conform, the
implementation must nonetheless do X. You're more likely to see such usage
with "recommended", however.

So if some author wrote "implementions must X" and really meant to say
"implementations MUST X", all that's missed is the reasoning; but an author
who wrote "implementations are recommended to do X", but really meant
"implementations SHOULD X" has changed the meaning (since
SHOULD/RECOMMENDED really means something much stronger than "recommended"
in normal English).

All that said it was fashionable a few years back to treat the RFC 2119
keywords as case-insensitive; I personally think this caused much more
trouble than it could possibly have solved.


> Anyway, one dirty Python program later, and it doesn't look like the most
> fun task for anyone (even considering only 'current' XEPs.) But from a
> quick look, most usage doesn't appear likely normative.
>
>
> *Dump follows…*
>
> Format is:
>  - one section per status (Active, Final, Draft, Proposed, Experimental)
>  - list of RFC-2119 magic words (upper and lower-case versions), with
> total counts for the section
>  - list of XEPs containing lower-case instances, and counts for each of
> those
>  - (negated-phrase counts are not separated, e.g. "MAY" is for both "MAY"
> and "MAY NOT")
>
> *** Active ***
>   MAY   102
>   MUST  145
>   OPTIONAL  4
>   RECOMMENDED   21
>   REQUIRED  3
>   SHALL 3
>   SHOULD251
>   may   210
>   must  62
>   optional  5
>   recommended   17
>   required  12
>   shall 111
>   should48
> XEP-0001required=1, should=10, must=31, may=43, shall=39, recommended=2
>

"it is not recommended for such implementations to be included in the
primary release for a software product" - delightful. "Primary releases of
a software product SHOULD NOT include such implementations" would be the
best RFC 2119 rewrite, but note that you can't use RFC 2119 to tell people
what to release. (And yes, we could also use NOT RECOMMENDED, with the same
caveat).

The uses of "shall" are interesting - they're often used in the same sense
of an edict that RFC 2119 intends, but it's not clear that these are RFC
2119 cases.


> XEP-0002must=1, may=4, shall=1
> XEP-0019should=1, may=2
> XEP-0049may=1
> XEP-0053should=1, must=3, may=7, shall=38
> XEP-0054should=2, must=1, may=3
> XEP-0055required=1, shall=1
> XEP-0068should=2, must=8, shall=1, recommended=1
> XEP-0076may=1, shall=1
> XEP-0082should=1, shall=1, recommended=1, optional=2
> XEP-0083should=3
> XEP-0100required=3, should=1, must=3, may=17, recommended=1
> XEP-0114may=1
> XEP-0127may=1
> XEP-0128must=2, may=4
> XEP-0132may=7, shall=11, recommended=2, optional=1
> XEP-0133may=46, shall=2
> XEP-0134should=1, must=5, may=3, shall=1
> XEP-0143required=3, should=5, must=1, may=8, recommended=1, optional=1
> XEP-0145required=1
> XEP-0147should=1, may=2, recommended=1
> XEP-0148may=5, shall=1
> XEP-0149should=1, may=9
> XEP-0153should=1, may=2, recommended=1
> XEP-0157required=1, should=1, may=9
> XEP-0160may=3, shall=1
> XEP-0169should=1, must=1
> XEP-0170may=2, 

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

[Dave Cridland]

On Wed, 10 Oct 2018 at 09:28, Ralph Meijer  wrote:

> 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".)
>
>
Yup. To every item. Maybe that's somewhere we could do some optimisation in
the protocol - although this is to deal with naive legacy clients so won't
help here.


> 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.
>
>
Yes, true.


> Section 4.2 (Items Nodes) also seems to imply that the node attribute
> for Service Discovery is not meant as a filtering mechanism.
>
>
Although we use it for precisely that in, for example, XEP-0050. I'm not
sure there's a real distinction here.

In general, I dislike "well-known nodes" because it means you can't
discover them, which feels rather against the point of XEP-0030.


> I am curious if just combining them would actually cause problems in
> practice. Has this been tested?
>
>
Nope. It just seemed like a pragmatic solution. It's not even clear to me
if any MUC clients actually use the disco#items at all. I know some *can*,
but I think only in generic "Service Discovery" UIs.

If MIX allows hundreds or thousands of participants in a channel, the MUC
disco interface is going to be pretty useless and/or deliberately
incomplete.


> --
> 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:
> >
> >  >   id='i

[Standards] XMPP Council Agenda 2018-10-03

[Dave Cridland]

Folks,

The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests marked "Needs Council".
* Trello at https://trello.com/b/ww7zWMlI/xmpp-council-agenda
* Random mails from Standards List
* Random suggestions directly to me.

I (try to) send out the final agenda about 24 hours in advance.

Agenda as follows:

1) Roll Call

2) Agenda Bashing

a) Highly likely I've missed something. Feel free to "pre-bash" if I have,
by replying to this.

3) Items for voting:

a) Proposed XMPP Extension: Bookmarks Conversion

Abstract:
This specification describes a method to migrate to PEP based
bookmarks without loosing compatibility with client that still use
Private XML.

URL: https://xmpp.org/extensions/inbox/bookmarks-conversion.html

b) Last Call: XEP-0359 (Unique and Stable Stanza IDs)

c) Last Call: XEP-0357 (Push Notifications)

4) Outstanding Votes

5) Next Meeting

6) AOB

7) Close

Note that I'm aiming for 30 minutes.

Meetings are normally held every Wednesday at 1500 UTC in the
xmpp:coun...@muc.xmpp.org?join chatroom. Meetings are open, and anyone
(XSF Member or not) may attend, though only XMPP Council members may
vote. Relevant comments from the floor are welcomed.

Thanks,

Dave.
(As Council Chair).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Generalisation of XEP-xxxx: MUC Avatars

[Dave Cridland]

On Tue, 25 Sep 2018 at 18:49, Timothée Jaussoin  wrote:

> I just reviewed the XEP-: MUC Avatars and I would like to discuss some
> ideas about it before proposing adjustments.
>
> The core idea of this XEP is to expose the Vcard hash in the bare MUC JID
> disco#info and notify it using a message 104.
> This is a really specific use case that solves a really specific problem.
>
> However the method that is used in this XEP to store this hash could be
> generalized to other cases.
>
> I see two things there:
> - How are we storing the avatar hash (here in a specific field in
> disco#info)
> - How this hash is advertised to the subscribers
>
> disco#info is a pretty generic feature in XMPP that is actually already
> applied to most of the resources available on the network
> including:
> - MUC JIDs
> - Users JIDs
> - Pubsub nodes
>
> What I'd like to propose is to generalize this XEP to allow this method to
> be used across all those resources, this will allow to have
> a unified method (it maybe sounds like https://xkcd.com/927/) to handle
> the retrieval of Avatars and also finally allow Pubsub nodes to
> have an avatar (and Vcard information as well if possible, see my last
> point).
>
> This brings me to the second part of my proposal. How to advertise the
> change.
> - For MUC, I'd suggest to stick with the status code='104' even if I'd
> prefer to use XEP-0153 presences for that
> - For Users JIDs, simply stick with XEP-0153
> - For Pubsub nodes it could also reuse XEP-0153 in a Pubsub notification
> as a payload
>
> Last proposal would not be to mention only Avatar but simply Vcard
> (vcard-temp in this case) then we could put more metadata in this
> payload (add an address to a Pubsub node for example) but I'd like to have
> more feedback on that one.
>
> In any cases I'll try to formalize those proposals in a PR to this XEP :)
>
>
This is a really good idea.

My only note is that for pubsub nodes, I'm a little concerned about
unilaterally sending XEP-0153 in a pubsub notification - but making that a
subscription option would alleviate that.

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

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

[Dave Cridland]

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  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:
>
>   id='ik3vs715'
>  to='hag66@shakespeare.example/UUID-c8y/1573'
>  type='result'>
>
>category='conference'
>  name='A Dark Cave'
>  type='mix'/>
>category='conference'
>  name='A Dark Cave'
>  type='text'/>
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>
>  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
>
>   label='Description'>
>  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
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XMPP Council Agenda 2018-08-08

[Dave Cridland]

Folks,

The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests marked "Needs Council".
* Trello at https://trello.com/b/ww7zWMlI/xmpp-council-agenda
* Random mails from Standards List
* Random suggestions directly to me.

I (try to) send out the final agenda about 24 hours in advance (hey, I
almost managed it this time!).

Agenda as follows:

1) Roll Call

2) Agenda Bashing

3) Items for voting:

[None!]

4) Outstanding Votes

5) Next Meeting

6) AOB

7) Close

Note that I'm aiming for 30 minutes.

Meetings are normally held every Wednesday at 1500 UTC in the
xmpp:coun...@muc.xmpp.org?join chatroom. Meetings are open, and anyone
(XSF Member or not) may attend, though only XMPP Council members may
vote. Relevant comments from the floor are welcomed.

Thanks,

Dave.
(As Council Chair).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Council Minutes 2018-08-01

[Dave Cridland]

On 6 August 2018 at 20:07, Georg Lukas  wrote:

> * Dave Cridland  [2018-08-06 17:54]:
> > > I’m pending being persuaded that the PR is right, rather than the
> original
> > > issue being a typo, BTW. -1 unless someone manages that (or similar).
> >
> > Therefore I concur with Kev, and hereby change my vote to -1.
>
> I fear I'm missing out on the logic here. If the original text in the
> XEP is a typo, and the PR removes that typo, shouldn't you vote +1 to
> get rid of the typo? Or is your desired change to make it sound as
> follows:
>
> | by simply sending a command/ with the 'node' attribute (and
> | optionally the 'action' attribute with a value of "execute").
>   ^^
>
>
The latter, I think. That's what the examples and §4.1 seem to suggest.

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

Re: [Standards] XMPP Council Minutes 2018-08-01

[Dave Cridland]

On 6 August 2018 at 16:45, Kevin Smith  wrote:

> On 6 Aug 2018, at 16:25, Tedd Sterr  wrote:
> >
> > http://logs.xmpp.org/council/2018-08-01/#14:59:59
> >
> > 1) Roll Call
> > Present: Sam, Dave, Kev, Georg
> > Pursuing business interests in the Middle Kingdom: Daniel
> >
> > 2) Agenda Bashing
> > No agenda changes; Georg liked it, but didn't put a ring on it.
> >
> > 3a) PR #681 - XEP-0050: Remove the status attribute from the request -
> https://github.com/xsf/xeps/pull/681
> > Dave thinks this seems like a pretty straightforward case of fixing the
> optional inclusion of an attribute that the receiver is mandated to ignore.
> Kev thinks it was the result of a typo ('status' instead of 'action'), and
> fixing the typo might be the better fix.
> > Sam wonders why there should be an optional attribute at all; Dave
> suggests it makes more sense if it's restating a default. Sam thinks it
> should still be required so it can be relied upon, otherwise it's
> cumbersome to have to check whether it's the default value or if it exists;
> Dave clarifies that if it's not the default value then it could be
> cancelling.
> > Dave asks Kev to make a comment noting the typo possibility [reply to
> minutes?], to spur Dave into investigating in more detail (and maybe
> there's an example that clarifies.)
> > Georg thinks Kev is right regarding the typo, but the PR is
> self-consistent and also removes the typo.
> >
> > Dave: +1
> > Sam: +1 (seems very sensible)
> > Georg: +1
> > Kev: [pending]
>
> I’m pending being persuaded that the PR is right, rather than the original
> issue being a typo, BTW. -1 unless someone manages that (or similar).
>
>
So after digging, I think Kev's right:

1) The schema includes an optional "status" attribute, but it doesn't have
"execute" as a possible value.
2) The schema does, however, include "action", which has the "execute"
value.
3) §4.1 notes that "action" is only set by the requester, and further notes
that "execute" is the default value.
4) All the examples are consistent with this being a typo - many requests
include "action" set to "execute" whereas none contain a status attribute.

Therefore I concur with Kev, and hereby change my vote to -1.

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

[Standards] XMPP Council Agenda 2018-08-01

[Dave Cridland]

Folks,

The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests marked "Needs Council".
* Trello at https://trello.com/b/ww7zWMlI/xmpp-council-agenda
* Random mails from Standards List
* Random suggestions directly to me.

I (try to) send out the final agenda about 24 hours in advance (hey, I
almost managed it this time!).

Agenda as follows:

1) Roll Call

2) Agenda Bashing

3) Items for voting:

3a) XEP-0050: Remove the status attribute from the request #681

https://github.com/xsf/xeps/pull/681

3b) Proposed XMPP Extension: File Sharing Notifications

https://xmpp.org/extensions/inbox/fsn.html

3c) XEP-0065, XEP-0363: Document exposing the service on the user’s domain
#682

https://github.com/xsf/xeps/pull/682

3d) Proposed XMPP Extension: Schrödinger's Chat

https://xmpp.org/extensions/inbox/muc-selfping.html

4) Outstanding Votes

5) Next Meeting

6) AOB

7) Close

Note that I'm aiming for 30 minutes.

Meetings are normally held every Wednesday at 1500 UTC in the
xmpp:coun...@muc.xmpp.org?join chatroom. Meetings are open, and anyone
(XSF Member or not) may attend, though only XMPP Council members may
vote. Relevant comments from the floor are welcomed.

Thanks,

Dave.
(As Council Chair).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Exact hint for Result Set Management

[Dave Cridland]

On 12 July 2018 at 12:24, Florian Schmaus  wrote:

> On 12.07.2018 12:39, Kevin Smith wrote:
> > On 12 Jul 2018, at 11:23, Matthew Wild  wrote:
> >>
> >> On 11 July 2018 at 18:25, Florian Schmaus  wrote:
> >>> On 11.07.2018 18:01, Matthew Wild wrote:
>  On 11 July 2018 at 16:33, Florian Schmaus  wrote:
> > I recently submitted PR #672 to the xeps repo
> >
> > https://github.com/xsf/xeps/pull/672
> >
> > to make users of RSM, like MAM, aware whether the result is exact or
> > not. It received some scepticism from the council members in today's
> > council meeting. I am to blame here as I thought the abstract
> motivation
> > in the commit message was enough. It appears it wasn't.
> >
> > While I think multiple applications could exploit that information,
> my
> > particular motivation was MAM. Consider the scenario where you have a
> > master archive and a local archive. The local archive may have
> multiple
> > holes at unknown locations. Now you want to sync your local archive
> from
> > the master using MAM/RSM.
> 
>  I'm not keen on this solution for the premise you've given.
> 
>  I don't believe that when using MAM correctly you would ever end up
>  with "holes at unknown locations" in your local archive. I don't think
>  that encouraging people to use a "bisection algorithm" is the right
>  thing to do.
> >>>
> >>> So you don't want MAM users to be able to efficiently sync archives
> with
> >>> multiple holes by a simple change because you do not want MAM to be
> used
> >>> in scenarios where this could happen?
> >>
> >> Just adding this flag will not make servers implement it, so it's
> >> going to add code and still need a fallback.
> >
> > And, as specified (optional but with no default or meaning for a missing
> flag) it seems unhelpful
>
> As Georg mentioned yesterday, the default is exact="maybe". There is
> also a sentence explaining the semantic of the missing hint:
>
> https://github.com/xsf/xeps/pull/672/files#diff-
> fd691aeb84210578723b940e9881ab7eR200
>
> > and as it adds a SHOULD, in a Draft XEP, with no namespace bump or
> > discovery, it’s adding ambiguity and confusion..
>
> I don't think that this is true, but we certainly can talk about making
> it just a recommendation if it is a blocker.
>
>
There's no difference.

>From RFC 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.



> - Florian
>
>
> ___
> 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] Detecting PEP support

[Dave Cridland]

On 9 July 2018 at 13:30, Tedd Sterr  wrote:

> One can certainly send a disco#info to server on which you don't have an
> account, and the response is as expected, but that still requires an
> account on _a_ server - so the reply can be directed to you.
>
>
This is probably the best bet. But note that it needs to be a real
(non-anonymous) account on another server...

a) If it's an Anonymous account on the same server, the server might not
offer PEP to anonymous users.

b) Even if it's on another server, servers can actually check for anonymous
users and alter their behaviour (Openfire does this sometimes).


> For pre-registration, I think support would have to be listed as a Stream
> Feature.
>

Right, we don't have a stream feature for this; but we do have a XEP-0115
stream feature - but without an account to expand that, it'd be tricky.


>
> That said, you could just try it -- connect to a server and send a
> disco#info without any 'from' attribute; but I would expect an error
> response.
>

If you don't get an error response from this (actually a stream error of
not-authorised I think), it's a bug.


>
>
> ___
> 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] XMPP Council Minutes 2018-06-20

[Dave Cridland]

On Sat, 23 Jun 2018, 12:24 Tedd Sterr,  wrote:

> http://logs.xmpp.org/council/2018-06-20/#15:00:27
>
> *1) Roll Call and Sandwich Orders*
> Present: Kev, Sam, Daniel
> Stuck in endless meetings: Dave
> Deep under-cover behind enemy lines: Georg
>

So... I wasn't stuck in meetings this time, instead I had a "family
emergency" (read: parents in law having a puncture) to deal with during the
meeting. Before that, I've a charity I try to help run stuck in a mire of
paperwork I'm trying to get through. Since then, though, I've been on
leave, driving about the UK with my son looking at universities, with
either the time or the bandwidth to deal with all this, but never both...

I'll be doing the same still tomorrow (no idea where I'll be during the
meeting - perhaps on the M1, possibly the M25 - we're doing London
university colleges next) - so I'll miss the meeting again I'm afraid.

Next week I was going to be away again... But I think I might not be now.
I'll try to get things back to normal. (Well the normal I aspire to anyway).


> *2) Isn't it nice that Tedd Sterr does the agenda?*
> [It's a dirty job, but somebody should do it.]
>

Thanks for filling this gap.


> *3) Advance XEP-0363: HTTP File Upload*
> Kev: [on-list] (without the agenda in advance, failed to look at this
> again)
> Sam: [on-list] (still nervous about the http headers stuff being too
> restrictive)
> Daniel: +1
> Dave: [pending]
> Georg: [pending]
>

I'm still pending on this one. My gut feeling is that the protocol is ready
for advancement but the specification of it is not - but I'll properly
review this before next week.


> *4) Deprecate XEP-0229: Stream Compression with LZW (and XEP-0138: Stream
> Compression)*
> Kev doesn't know why this appeared on the agenda - Daniel thinks it was
> voted on 6 months ago - Kev agrees that it did come up before.
> Daniel thinks it's probably due to perceived insecurity; Kev sees that
> there was a vote in April not to advance it.
>
> Sam: +0
> Kev: -0
> Daniel: -0
> Dave: [pending]
> Gerg: [pending]
>
> Daniel thinks compression is generally nice to have, and maybe this could
> be made secure with proper business rules.
> Sam agrees that compression is nice to have, but isn't against getting rid
> of it.
> Kev says that some sort of compression is desirable, as XMPP is heavily
> compressible and sometimes used on poor links.
> Daniel thinks this issue should be revisited soon. Kev agrees - it could
> be Stream Compression, or EXI (XEP-0322), or something else - but
> deprecating isn't the Right Thing™ at the moment; Sam agrees.
>

Well... I certainly wouldn't deprecate XEP-0138. But I probably would
deprecate XEP-0229.


> *5) Outsanding Votes et les Vol-au-vents*
> [Georg had two -- now done:
> https://mail.jabber.org/pipermail/standards/2018-June/035191.html]
>

Ooooh. I now have outstanding voles.

I'll put Georg's into the Spreadsheet of Doom... At some point. (Home at
the weekend, I'll try to remember then).


> *6) Next Meeting, Next Meal*
> 2018-06-27 1500 UTC
>
> *7) Bier und AOB*
> Nobody shouts imminently.
>
> *8) Close and Take Your Rubbish Home with You*
> Thanks all; show's over!
>
>
> *Discussion of EXI continues...*
>
> ___
> 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] OMEMO Next

[Dave Cridland]

Short answer: Yes, see the MLS work within the IETF.

On Tue, 26 Jun 2018, 15:00 Niels Ole Salscheider, <
niels_...@salscheider-online.de> wrote:

> Hi,
>
> when XEP-0384 (OMEMO) became experimental last year, it was said that it
> was
> to document what was implemented at that time in the real world, based on
> SignalProtocol. Yet the idea was to continue work on "OMEMO Next" which
> would
> address the problematic bits of the current XEP and make it less dependant
> on
> libsignal-protocol and its wire format.
>
> Has there been any work on this? Are there any plans about how to continue?
>
> Best regards,
> Ole
>
>
> ___
> 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] XMPP Council Minutes 2018-06-13

[Dave Cridland]

On 13 June 2018 at 21:59, Tedd Sterr  wrote:

> http://logs.xmpp.org/council/2018-06-13/#15:03:33
>
> Dave apologises for not preparing an agenda; apparently, having a day job
> is distracting.
>
> *1) Roll Call*
> Present: Kev, Daniel, Sam, Dave
> Away on a top-secret mission: Georg
>

*1½) Isn't it Nice when Tedd Sterr does the minutes?*

>
> *2) Agenda Bash*
> Dave is unaware of anything that needs a vote, and asks whether anyone
> knows of anything; all minds are blank.
>
> *e) Outstanding and Mediocre Votes*
> Dave checks that Sam did veto 'the MUC thing' (PR #653) - he did; Georg
> has two votes outstanding.
>
> *3) Next Meeting*
> 2018-06-20 1500 UTC, hopefully with Dave preparing an agenda and picnic.
>
> *π) AOB*
> Daniel mentions that the LC for HTTP Upload was issued last week, but
> hasn't yet received any feedback; he assumes this is because the feedback
> from the previous LC has already been addressed. Daniel also checks that
> Council will be okay voting despite the (latest) lack of feedback, and if
> he should bump the thread in an attempt to encourage new feedback.
> Kev suggests that Council can vote next week after looking at the feedback
> from both LCs.
> Dave comments that no feedback is also a form of feedback.
> Daniel was worried because past votes have been postponed due to a lack of
> feedback; Dave doesn't think it's a necessity, but sometimes the silence is
> a cause for concern. Kev seconds that a lack of feedback suggests something
> shouldn't be advanced, but if it's likely that feedback just needs to be
> encouraged then the vote can be delayed; and there was already a lot of
> feedback from the last LC.
> Sam and Kev agree that it's worth poking to see if there is further
> feedback.
>
> *4) Close*
> Dave apologises for the somewhat useless meeting.
>
>
> ___
> 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] Network IO best practices

[Dave Cridland]

On 10 June 2018 at 06:09, Daniel Corbe  wrote:

> Because it would seem to me as if one would need to read the entire stream
> one byte at a time and wait for valid input before passing the message off
> to a parser.   IE, I’m looking for that final closing > before I can reply.
>
>
Eeeek.


> Is there a better way to go about it that isn’t going to incur a massive
> performance penalty?
>

Yes, there's two.

Either:

a) Use a SAXish parser and count events.

b) Use an XML parser that allows you to extract the right XML "bits" - more
or less, an element open and individual elements. For example, my fork of
rapidxml offers this. It's probably the parser doing (a) internally in most
cases, though.

If its any consolation, the implicit framing in XMPP is generally regarded
as something less than ideal that we're stuck with - but on the other hand
it's a thoroughly solved problem now.

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

Re: [Standards] XMPP Council Minutes 2018-05-30

[Dave Cridland]

On 6 June 2018 at 17:30, Jonas Wielicki  wrote:

> On Mittwoch, 6. Juni 2018 16:52:27 CEST Sam Whited wrote:
> > I'm not af an of how this one was done. -1 for now. I'd like to discuss
> how
> > this can be done better though; it seems to me that it would fit very
> well
> > as part of extensible IBR and/or SASL2.
>
> I agree that IBR or SASL2 or whatever integration is needed, but
> restricting
> it to that is not sufficient. I planned to add this post-acceptance. (I
> don’t
> want to open the "Develop things in Experimental vs. in ProtoXEP state"
> box
> now.)
>
> Here’s why I think only IBR/SASL2/other-pre-auth-things is not sufficient:
>
> 1. Long-living sessions need to be notifiable. You could of course kill
> the
> connection, have it re-authenticate, show the user the info box, and hope
> they
> read it in time for stream management resumption to work, but I don’t
> believe
> that to be a good flow. I’d like to avoid blocking clients on
> authentication
> until absolutely necessary (i.e. deadline for agreement reached). Until
> then,
> a way to notifiy users about changes and a way for them to acknowledge
> those
> changes (and give agreement to whatever necessary/wanted) seems useful.
>
> 2. This kind of doubles as kind of privacy settings, and I agree that this
> might be feature creep and we might want to split this off. I find it
> logical
> to combine those two things though. Especially in GDPR-land a service
> might
> want to offer their opt-in things next to the terms of service so that
> users
> don’t have to dig for them. In non-GDPR-land where there may exist
> mandatory
> opt-in things, it makes sense to have them right next to the ToS in the
> client. For non-mandatory opt-in things, it makes sense to be able to
> change
> them even when a ToS change is not around the corner, so having an
> IQ/Ad-Hoc
> flow for that makes sense.
>
>
> I see that the IQ-based pre-auth flow is an issue, and integrating this in
> SASL2 or something is probably the better way to handle this. However,
> this
> also needs to work pre- or during IBR in some way.
>
> I am hesitant to base anything on SASL2 with the current state of
> deployment
> there.
>
>
> I also accept the criticism I got from other folks (Kev I think, but don’t
> quote me on that) that the Ad-Hoc workflow looks out of place. I’ll work
> on
> that, but first I want to be on the same page with you, Sam, because I
> don’t
> want to waste more time on a spec which will be -1'd.
>

Right, I'm probably +1 for all the same reasons as Sam is -1, oddly enough.

We need a ToS mechanism, I think. We also, as you point out, need one
that's IQ-based and can be actuated in mid-stream - this is going to be
useful in cases such as a ToS policy for muc.xmpp.org. It'd be great if
this mechanism builds on ad-hoc, as this one does.

But we also need something that'll work before the login. There's a number
of deployments I work on where the organisation would probably want a ToS
ack before (or during) *every* login - currently they work with MOTD
plugins and similar, but that's clearly not ideal.

I really don't want to have any IQ based flows prior to login if possible -
with my server-dev hat on, I find it worrying to have to do deep inspection
of IQ stanzas during pre-auth.

SASL2 et al will go some way to addressing these, but won't satisfy legacy
clients - maybe that's going to have to be good enough, or maybe we'll
figure out something better.

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

Re: [Standards] XMPP Council Minutes 2018-05-30

[Dave Cridland]

On 31 May 2018 at 01:22, Tedd Sterr  wrote:

> http://logs.xmpp.org/council/2018-05-30/#15:00:13
>
> *1) Roll Call* - https://en.wikipedia.org/wiki/Roll_Call
> Present: Kev, Daniel, Georg, Sam
> Better things to do: Dave
>
> *2) Isn't it nice that Tedd Sterr does the minutes?*
> There are no dissenting voices.
>
> *3) Proposed XMPP Extension: Terms of Services* -
> https://xmpp.org/extensions/inbox/tos.html
>
> Kev: +1 (don't like this much, but not blocking it)
> Daniel: [to vote on-list]
> Georg: +1 (it's great to have a machine-readable way to link the ToS; not
> sure about the extended features)
> Sam: [to vote on-list]
> Dave: [pending]
>
>
I think this is a great concept, but a poor implementation (with
silly-states - we can say agreement is required, and block resource binding
until this is so, but we cannot gain agreement until the client is
resource-bound).

Nevertheless, I think it's sufficiently useful we should fix it, so +1 (but
it'll never advance in this form).


> *5) Next Meeting*
> 2015-06-06 1500 UTC appears okay, though Georg still can't guarantee
> availability for this time slot, but it seems to have mostly worked so far.
>
> *4) AOB*
> Daniel wants to further HTTP Upload, but is unsure if that should be
> another LC, or it can be voted into Draft; additionally noting a small
> pending PR. Kev suggests LCs are cheap, so LC after the PR is merged.
> Georg has concerns about the custom headers, but not enough to block
> progress.
> Daniel was hoping to speed things along, but as it's already been months,
> will bring it up again next week.
> Kev suggests a clean cut with a new LC would be best; alternatively, ask
> Editors to LC after the PR is merged. Daniel opts for the latter.
>
> *6) Close*
> Kev gangs the bavel and thanks all.
> Georg thanks Kev, all, and Tedd.
>
> ___
> 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
___

[Standards] XMPP Council Agenda 2018-06-06

[Dave Cridland]

Folks,

The XMPP Council will be holding it's regular meeting tomorrow (Wednesday)
at 1500 UTC. The agenda is collated from (in order of reliability):
* Github pull requests marked "Needs Council".
* Trello at https://trello.com/b/ww7zWMlI/xmpp-council-agenda
* Random mails from Standards List
* Random suggestions directly to me.

I (try to) send out the final agenda about 24 hours in advance.

Agenda as follows:

INTRO:

1) Roll Call [https://en.wikipedia.org/wiki/Roll_Call_(Hank_Mobley_album)]

2) Isn't it nice that Tedd Sterr does the minutes?

3) Proposed XMPP Extension: OMEMO Media sharing

Title: OMEMO Media sharing
Abstract:
An informal way of sharing media files despite limitations in the
OMEMO encryption

URL: https://xmpp.org/extensions/inbox/omemo-media-sharing.html

4) Proposed XMPP Extension: Ephemeral Messages

Title: Ephemeral Messages
Abstract:
This specification defines a protocol to send ephemeral messages over
XMPP and synchronize timer value setting across devices.

URL: https://xmpp.org/extensions/inbox/ephemeral-messages.html

5) Outstanding Votes

6) AOB [https://en.wikipedia.org/wiki/Abom_language]

7) Next Meeting

8) Close

Note that I'm aiming for 30 minutes.

Meetings are normally held every Wednesday at 1500 UTC in the
xmpp:coun...@muc.xmpp.org?join chatroom. Meetings are open, and anyone
(XSF Member or not) may attend, though only XMPP Council members may
vote. Relevant comments from the floor are welcomed.

Thanks,

Dave.
(As Council Chair).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Should we move Nicks out of MIX-CORE?

[Dave Cridland]

Nicknames are what users use to refer to each other. If, in a channel, I
say, "Steve, that's a terrible idea!", then I'm referring to the user whose
nickname is Steve in the channel.

If we say clients should name channel occupants by any name they like, this
won't work. We'll then have to handle things by references - a better idea,
certainly, and one that solves the question of who I'm talking to.

But then in the text, you'd still see what name I use to refer to you as...

Now, as it happens, you're simply Steve Kille in my roster - hooray for
posting on good terms, eh? - but what if I'd got a silly name for you? Or
misspelled your name? Autocorrect really hates it, after all.

These aren't technical interoperability, but they do harm to user
experience and might even be a privacy leak.

On Mon, 4 Jun 2018, 19:53 Steve Kille,  wrote:

>
>
>
>
> *From:* Standards  *On Behalf Of *Dave
> Cridland
> *Sent:* 04 June 2018 19:11
> *To:* XMPP Standards 
> *Subject:* Re: [Standards] Should we move Nicks out of MIX-CORE?
>
>
>
>
>
>
>
> On 4 June 2018 at 07:53, Steve Kille  wrote:
>
> This can be a client choice.   The client could show JID, or MIX provided
> Nick, or a user-assigned Nick for the participant.   MIX is not mandating
> what gets shown.
>
>
>
> I actually think it should have an opinion on what the client shows, at
> ;least when MIX is being used for "chatrooms".
>
>
>
> Otherwise there's a risk that different clients end up having such
> radically different user interfaces that interoperability is hampered at
> the user level.
>
>
>
> I have vague recollections of this being a problem in other cases - didn't
> Georg do some work on common terminology and suchlike?
>
>
>
> Dave.
>
> *[Steve Kille]*
>
>
>
> *Having MIX mandate what is shown or not show in a client UI is drifting
> into very dangerous territory.  *
>
>
>
> *Steve*
>
>
> ___
> 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] Should we move Nicks out of MIX-CORE?

[Dave Cridland]

On 4 June 2018 at 07:53, Steve Kille  wrote:

> This can be a client choice.   The client could show JID, or MIX provided
> Nick, or a user-assigned Nick for the participant.   MIX is not mandating
> what gets shown.
>

I actually think it should have an opinion on what the client shows, at
;least when MIX is being used for "chatrooms".

Otherwise there's a risk that different clients end up having such
radically different user interfaces that interoperability is hampered at
the user level.

I have vague recollections of this being a problem in other cases - didn't
Georg do some work on common terminology and suchlike?

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

Re: [Standards] Requirements for "Jid Hidden" Channels

[Dave Cridland]

On 2 June 2018 at 17:36, Steve Kille  wrote:

> It is clear that much of the complexity around JID encoding that is being
> postulated as necessary, ties back to requirements to support participant
> communication through  JID Hidden channels.
>
> This note is to step back from the JID discussion, and consider JID Hidden
> channel requirements.
>
> I'm writing out a list of requirements here, which I think when agreed,
> could be usefully used as part of the introductory material to MIX-ANON.
>
> With JID Visible channels,  real JIDs are shared and participants can use
> this to communicate directly.
>
> When looking at MIX requirements, quite a few argued that we should not
> have
> JID Hidden.  A lot of other chat systems (e.g., Facebook) do not have an
> equivalent of JID Hidden.   I think that many channels will be JID Visible.
>
>
That's not been the case, though, historically. Most MUC rooms are
anonymous.


>
> It was agreed clearly that we need JID Hidden, primarily to prevent JID
> Harvesting.   This is going to be useful for public and semi-public
> channels.
>
> REQUIREMENTS:
>
> 1.  Participants can see which other participants have one or more online
> clients.
>
> 2.   Online participants can be displayed with a Nick.
>
> 3.   Participants MUST be able to see if another participant changes Nick.
>
> 4.Participants can sent messages to other participants through the
> channel if channel policy allows this.
>
> 5.A participant can share real JID with another participant and request
> real JID.   Can't do this currently, but it seems sensible to allow a pair
> of willing participants to shift from restricted communication through the
> channel to direct communication.
>
>
> POSSIBLE REQUIREMENTS:
>
> 6.   Participants can share presence status additional to online/offline.
> I am wondering if, in an environment where JIDs are being hidden, if it
> makes sense to share other presence stuff with  the channel.   My sense is
> that for a public MUC, it might make sense to restrict.   I would vote to
> make this a non-requirement.
>
>
If we assume that people will use MIX in the same way MUC is typically
used, then presence is usually (intentionally, I think) shared amongst
anonymous participants.


>
> 7.   Where a participant has multiple clients, other participants can see
> independent status of these clients.   I think that this is not appropriate
> for JID Hidden channels.  If you are not sharing your JID, it feels wrong
> to
> be sharing how many clients you have.
>
>
I this this depends on *why* you're hiding your JID.

In some cases, people are after perfect anonymity. In general, I think we
should ensure that it is possible to have a MIX channel which JIDs are
completely hidden (which probably includes avoiding pass-through for IQ,
etc in those cases). The two cases I can think of are the e-health case,
where we want to be able to assure participants that their identity is
secret, and the legal case where corporations wish to participate in some
collaborative venture without being definitively identified. (Cyber
collaboration, or collaborative security, is an example of the last case).

In most cases, though, people seem to want to hide their JID, but not hide
their identity. This seems to be the case in the vast majority of MUC rooms
I'm in, in fact. Your point (5) would be very useful here, since it would
allow, in principle, to subscribe to your presence through a chatroom,
which is (pretty much) the use-case here.


>
> NON REQUIREMENTS
>
>
> 8. vCard.   If you are hiding your JID,  it seems wrong to allow retrieval
> of generic information about you.   I think that getting vCard information
> about other participants should be explicitly excluded.
>
>
Well, it does seem a bit crazy - and why, back when I did the higher level
MUC implementation in M-Link, I explicitly made passing through vCard
requests an option. But it turns out most people usually want this for
avatars if nothing else.


>
> 9.  Client Disco.   I think that allowing clients to use IQ disco of JID
> Hidden participants is wrong.  If you feel that JID should be hidden, it
> does not make sense to
>
>
Totally disagree. This blocks nearly every elective feature of XMPP being
used.

You might think an anonymous client will never want to do, say, voice
calls, but I suspect that's only true if the goal is true anonymity - in
which case burner jids are more useful. In practise, though, things like
focus users in conference systems work using this.


>
>
> I appreciate that this has switched topics.   I think that getting some
> agreements here, would help to sort the JID discussion.
>
> Can we keep this thread on "JID Hidden" and see if we can agree
> requirements?
>
>
>
>
>
> Steve
>
>
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

Re: [Standards] Addressing for IQs in MIX-CORE

[Dave Cridland]

On 4 June 2018 at 15:43, Jonas Wielicki  wrote:

> I think this is a good point, and I’ve run into this quite a few times
> when
> implementing MUC. Branching on the message type where 'groupchat' is
> somehow
> special, but then again only if it does *not* come from the bare JID, and
> if
> it *does* come from the bare JID, you may be confused (but that happens,
> in
> fact). And non-groupchat messages from the bare JID have a different
> semantics
> than non-groupchat messages from the occupant JID (I’m only talking about
> MUC
> here). This is weird, and I think if MIX does away with that, that would
> not
> be too bad.
>
>
I'm not sure that type=groupchat messages from the '45 chatroom bare jid
are different from type=groupchat messages from the '45 occupant bare jid
except in who they're from, are they? I mean, they're different because
they're from the chatroom itself, of course, but beyond that?

Well, errors, I suppose, come from the bare jid, but they're not groupchat
of course.


>
> A random side note: I found another argument against the variant where the
> client resource is encoded together with the participant id in the
> resource:
> The client resource is -- in contrast to the channel name and participant
> id
> -- not under control of the MIX service. A client resource can be very
> long
> (although it probably isn’t right now), and that would break things.
> Combining
> the participant ID and channel name in the nodepart allows the MIX channel
> to
> control both parts to always fit in a nodepart (restricting the length of
> the
> channel name most likely).
>
>
> kind regards,
> Jonas
> ___
> 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] Addressing for IQs in MIX-CORE

[Dave Cridland]

On 4 June 2018 at 14:37, Kevin Smith  wrote:

> On 4 Jun 2018, at 12:15, Dave Cridland  wrote:
> >>
> >>
> >>
> >> On 4 June 2018 at 11:37, Steve Kille  wrote:
> >>
> >> To support IQs in MIX-CORE, there needs to be an addressing  and routing
> >> scheme.
> >>
> >> I am proposing that this uses a different scheme to messages from the
> >> channel (this is Kev's variant 4).
> >>
> >> The rationale for having a different scheme is that you want to be able
> to
> >> distinguish from a stanza that comes from the channel, from a stanza
> (IQ)
> >> that is relayed by the channel.
> >
> >
> > I think that's a false dichotomy. 
>
> I think calling out the language here might be a fair call (although I
> don’t find it too confusing), but I think the underlying dichotomy is still
> there. Some stanzas are sent in the context of fanout to potentially all
> participants, and some are sent to be distributed in private to a single
> participant.
>

That's somewhat different - but even here, you're arguing to change the
*from* address depending on where it's been sent *to*?


>
> >> A message distributed by the channel would come from:
> >> channel@domain/stable-participant-id
> >>
> >> Bare JID is the channel, reflecting that the message comes from the
> channel.
> >>
> >> An IQ message being relayed by the channel would come from:
> >> stable-participant-id#channel@domain/resource
> >>
> >> Bare JID reflects the sender, which will enable the receiver to clearly
> >> distinguish that this is not coming from the channel.
> >>
> >> We want to use this scheme for PMs (MIX-ANON), and here the difference
> >> becomes more important.   You want to clearly distinguish messages from
> the
> >> channel from PMs, and this approach gives a framework to achieve this.
> >>
> > So type='groupchat' is no longer enough?
>
> Yes, that’s surprising isn’t it?
>
> I came to this realisation a couple of days ago, not just that it’s no
> longer enough, but that it never was really adequate and definitely not
> ideal.
> A few reasons:
>
> * Elsewhere in XMPP, the ‘to’ alone is used to determine which entity
> receives a stanza (I’m terminating entities at the user, not each of their
> devices, for these purposes). That here the difference between sending to a
> whole group of people and a single person is predicated not on the address,
> but the message type, is cause for us to think twice.
>

I'm not sure how the to address isn't still governing how receives the
stanza. You're arguing for changing the from here, aren't you?


> * I have seen multiple bugs from people who are not XMPP-naive in this
> area, because it’s very easy to slip when the to no longer gives you
> addressing (including security issues). This makes it easy to shoot
> yourself in the foot.
>

Same - a message stanza from A to B has been sent from A to B. The type
indicates who *else* has received this. No?


> * Even where it doesn’t end up in a bug, I’ve seen bad UX resulting from
> this.
> * Querying a MAM archive becomes ‘interesting’ when you want to query just
> room messages, or just PMs with a particular occupant
>

This is an interesting and valid point, i think. I'm not convinced it's
outweighing the address altering depending on the traffic used though.


>
> there are others, but this is a reasonable flavour, I think.
>
> Now, one might assert that it’s not worth changing this in MUC, but in MIX
> where we have the chance to avoid all these issues it seems worth giving
> serious thought to alternatives.
>

Absolutely - but I'd argue we want the addressing consistent irrespective
of the traffic.


>
> /K
>
> ___
> 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] Addressing for IQs in MIX-CORE

[Dave Cridland]

On 4 June 2018 at 11:37, Steve Kille  wrote:

>
> To support IQs in MIX-CORE, there needs to be an addressing  and routing
> scheme.
>
> I am proposing that this uses a different scheme to messages from the
> channel (this is Kev's variant 4).
>
> The rationale for having a different scheme is that you want to be able to
> distinguish from a stanza that comes from the channel, from a stanza  (IQ)
> that is relayed by the channel.
>
>
I think that's a false dichotomy.

Whether a stanza is "relayed" or not really depends on your viewpoint.

For example, some people see messages as relayed, and others see them as a
notification from the channel that a new message was submitted.

You might say that IQs are relayed; I might argue that they're serviced by
the channel - and the channel may service them by, itself, performing an
equivalent IQ.


> A message distributed by the channel would come from:
> channel@domain/stable-participant-id
>
> Bare JID is the channel, reflecting that the message comes from the
> channel.
>
> An IQ message being relayed by the channel would come from:
> stable-participant-id#channel@domain/resource
>
> Bare JID reflects the sender, which will enable the receiver to clearly
> distinguish that this is not coming from the channel.
>
> We want to use this scheme for PMs (MIX-ANON), and here the difference
> becomes more important.   You want to clearly distinguish messages from the
> channel from PMs, and this approach gives a framework to achieve this.
>

So type='groupchat' is no longer enough?


>
>
> Thoughts?
>
>
> Steve
>
>
>
>
>
>
>
>
>
> ___
> 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] Group chat protocol

[Dave Cridland]

On 3 June 2018 at 15:30, Ненахов Андрей 
wrote:

> To whom it may concern, we're working on group chat solution for XMPP.
>
> It is quite a simple solution that we feel is good enough to counter most
> issues of XEP-0045.
>
> It is quite simple:
>
>- Group chat is listed in a roster, we use standard xmpp subscription
>to join-leave group chats
>
> So you're thinking that a presence subscription to a groupchat should
equate to a groupchat message subscription (but not, as I understand
things, a groupchat presence subscription)?

That sounds pretty horrible, but I see why you've done it.

>
>- Clients can differentiate group chat contacts from regular contacts
>in their rosters by a specially formatted presence.
>
> I think that's the case with '45. Seems fine, as long as you're "specially
formattng" by just plonking in an extension element.

>
>- Sending messages to group chat is done by sending messages to group
>chat JID
>
> (Same as '45?)

>
>- Group chat server resends messages to everyone but sender with
>special formatting, that includes unique message ID, sender nickname,
>sender JID, avatar hash. For older clients, we provide a plaintext body
>that starts with *nickname:\n *before actual message.
>This way allows a client to display everything they need without
>fetching data from a list of group chat members. Avatar hash is also a
>filename so avatar can be retrieved from a server when needed.
>
> I'm fine with stuffing data into the messages, in general terms. I worry
about putting routing info in, but I can live with it. Stuffing data into
the text is very horrible.

>
>- Non-anonymous groups transmit real user JID, semi-anonymous transmit
>JID assigned to this user for identification purposes.
>- Nicknames and avatars are retrieved from user's vCard when he joins
>the group. Can be redefined later by user
>
> I'd be a little concerned with that approach in anonymous rooms, but I
think that the general principle of the service pulling information from
the endpoint for relay is fine.

>
>- No private messages support. XMPP is already a protocol for private
>messaging. In non-anonymous groups users can contact each other directly.
>In semi-anonymous groups, users can send a special message (via group) to
>other users that would disclose their real JID to the user they want to
>talk to. If the recipient accepts he can add him to his personal roster and
>chat privately.
>
> Yeah, that's definitely something I disagree with.

I see two problems immediately:

* Sometimes, anonymous users are anonymous because they want to interact,
even in PM, without disclosing their identity. This is particularly true -
I think - in e-health cases (though ask Winfried Tilanus about that).
* Sometimes, occpuants of a groupchat can be services (bots and other
things) which really benefit from knowing the context of the interaction -
ie, which room this is.

So I think having PMs is useful - this is unfortunate, because otherwise a
"decloak" is indeed much cleaner and simpler to implement.

>
>- Clients can fetch a list of group chat members and turn on/off
>receiving updates. We imagine users of big groups of 300+ users don't
>really want to receive presence data all the time, but might want to open a
>list of participants and see who's online.
>
> Seems fine. I think this is in MIX too.


> Group chat also provides a centralized message archive, so members can
> fetch chat history directly from group chat server.
>
> Advantages of this approach:
>
>- Simple
>- Compatible with existing clients
>- Compatible with existing servers
>- Easy to implement in any XMPP client
>
> Parts of it are already implemented (we run it on modified ejabberd), we
> already use it for internal communications. It is also already supported in
> a web version of Xabber. I expect a mid-July release with support in Web,
> Android and iOS versions of Xabber. Most likely we'll also make a Gajim
> plugin, but a bit later and maybe not fully featured.
>
> Admin stuff is not yet done. Most likely will be somewhat akin to Telegram
> group chats model. Admins can be granted rights by owners and other admins,
> users can be restricted by admins.
>
> Anyone interested to try it can connect with me xmpp:andrew.nenakhov@
> redsolution.com, I'll invite you to existing groupchat we made. Best way
> to try is to connect using development version of Xabber,
> https://web.xabber.com/develop/
> For now, it's limited (and sometimes breaks ;) ) and you can only join
> already created group chats, I think we'll also add permissions for
> anyone to create group chats on our server.
>
> ...
>
> Documentation for all of this is now in a somewhat inconsistent state (and
> is also in Russian), we changed a number of things from our original plan
> and our proto-protocol spec is now already outdated at some places, I plan
> to fix it next week and