Re: [Standards] XEP-0313 for transports

[Jonas Schäfer]

4 Mar 2020 4:36:08 pm Kevin Smith :

> On 26 Feb 2020, at 17:24, Jonas Schäfer < jo...@wielicki.name 
> [mailto:jo...@wielicki.name] > wrote:
>
> >
> > On Mittwoch, 26. Februar 2020 16:40:06 CET Ivan Vučica wrote:
> >
> > > Hi,
> > >
> > > Sometimes, protocols backing transports may support querying for an
> > > archive similar to how it's done with XEP-0313.
> > >
> > > tl;dr Can querying archives on non-own, non-MUC, non-pubsub JID for
> > > 1:1 chats be standardized? Can it be standardized that server
> > > implementations don't have to support date-based queries?
> > >
> > >
> > >
> > > 1. XEP-0313 is specified for archives maintained by the user's own
> > > server. Section 3.3 doesn't specify that a client can query a remote
> > > JID for the archive, which would be useful for transports. It does
> > > specify it for MUC and pubsub, but not for 1:1.
> > >
> > > Here I'm mainly interested: Are there clients that would query a
> > > remote JID for the archive today, despite XEP-0313 not requiring
> > > servers nor clients to support this? Under which conditions would they
> > > do this?
> > >
> >
> > Ugh. No, I don’t think any client would query a remote JID for 1:1 archives.
> >
>
> Why not? MAM’s just a mechanism for querying archives for messages, surely it 
> shouldn’t matter where the archive is?

I meant "right now as it stands".

--
Jonas Schäfer
This was sent from mobile, and I'm not good with those. Sorry for brevity and 
such.

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

Re: [Standards] XEP-0313 for transports

[Kevin Smith]

On 26 Feb 2020, at 17:24, Jonas Schäfer  wrote:
> 
> On Mittwoch, 26. Februar 2020 16:40:06 CET Ivan Vučica wrote:
>> Hi,
>> 
>> Sometimes, protocols backing transports may support querying for an
>> archive similar to how it's done with XEP-0313.
>> 
>> tl;dr Can querying archives on non-own, non-MUC, non-pubsub JID for
>> 1:1 chats be standardized? Can it be standardized that server
>> implementations don't have to support date-based queries?
>> 
>> 
>> 
>> 1. XEP-0313 is specified for archives maintained by the user's own
>> server. Section 3.3 doesn't specify that a client can query a remote
>> JID for the archive, which would be useful for transports. It does
>> specify it for MUC and pubsub, but not for 1:1.
>> 
>> Here I'm mainly interested: Are there clients that would query a
>> remote JID for the archive today, despite XEP-0313 not requiring
>> servers nor clients to support this? Under which conditions would they
>> do this?
> 
> Ugh. No, I don’t think any client would query a remote JID for 1:1 archives. 

Why not? MAM’s just a mechanism for querying archives for messages, surely it 
shouldn’t matter where the archive is?

As concrete examples of when it might make sense to query non-MUC, non-private 
archives:
* An appropriately privileged user querying the archives of other organisation 
members (e.g. HR in case of harassment cases)
* A system that presents a single outgoing JID that is controlled by several 
users (e.g. shift workers handling a support address)

While it might not be a standard personal IM-client feature, I don’t think that 
means it’s not valid, or that we need to disallow it.

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

Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts

[Sam Whited]

On Tue, Mar 3, 2020, at 12:45, Jonas Schäfer wrote:
> 3. Is the text of XEP-0184 clear and unambiguous? Are more examples
>needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
>Have developers found the text confusing at all? Please describe
>any suggestions you have for improving the text.

It's a minor nit, but we could replace the reference to Message
Archiving with MAM instead. It's a minor change that doesn't actually
break any important draft rules as far as I know but makes the spec feel
more up to date (for now) and just generally provides users with a more
useful link. All this may change in the future, but it seems like good
housekeeping at the moment.

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

Re: [Standards] Council Minutes 2020-02-26

[Kevin Smith]

On 4 Mar 2020, at 15:00, Dave Cridland  wrote:
> 
> 
> 
> On Wed, 4 Mar 2020 at 10:23, Daniel Gultsch  > wrote:
> Am So., 1. März 2020 um 01:14 Uhr schrieb Tedd Sterr  >:
> > 4b) Advance XEP-0198 (Stream Management) - 
> > https://xmpp.org/extensions/xep-0198.html 
> > 
> > Georg is unsure, but it's doing its job, expect for the unclear resume host 
> > connection mechanism.
> > Dave noted a comment on s2s, possibly from MattJ, which he has yet to 
> > consider, but s2s is under-specified at best.
> > Jonas doesn't think it's possible to move forward if there are zero s2s 
> > implementations; Dave doesn't think any were explicitly mentioned, which 
> > would itself be a procedural reason for not advancing.
> > Zash mentions that mod_smacks for Prosody does support XEP-0198 in s2s, 
> > though not resumption, and it's disabled by default - Dave thinks it's 
> > unclear what resumption would do for s2s.
> >
> > Jonas: [on-list] (yet to catch up on the thread)
> > Daniel: -1 (people have brought up valid, but fixable, concerns)
> > Zash: -1 (haven't read that thread yet)
> > Dave: -1 (lack of clarity on s2s implementations)
> > Georg: -1
> 
> 
> Do we have a way forward with this that isn’t just ignoring it?
> Are any of the authors who are still active in the community (looking
> at you Matt and Dave) willing to incorporate whatever the consensus is
> on how to proceed?
> 
> 
> Sure.
>  
> Do we want to eliminate s2s from the XEP?
> 
> 
> I don't know. Mostly, I don't know if anyone implements it. I'm pretty sure 
> M-Link does on S2S, because I think I put it there - but whether anything 
> else does I don't know.
>  
> Are server developers interested in implementing 198 s2s?
> 
> 
> I might, in Metre. But I'd definitely only do acks, not resumption - I don't 
> think there's any value on resumption for S2S.

I think there is value actually (despite M-Link not doing it) because it, in 
principle, allows retransmission of stanzas without duplication.

/K

>  
> Personally I would hope for the latter. But I’m not a server
> developer; Maybe it's more complicated or unnecessary as it seems.
> 
> 
> >
> > 4c) Advance XEP-0368 (SRV records for XMPP over TLS) - 
> > https://xmpp.org/extensions/xep-0368.html 
> > 
> > Travis Burtrum promised to make some changes to XEP-0368, mostly clerical, 
> > and changing a SHOULD to a MAY.
> >
> > Jonas: -1 (changes need to be made)
> > Georg: -1 (liked the proposed wording)
> > Zash: [on-list]
> > Daniel: [on-list] (not caught up on that)
> 
> -1. I think there is consensus for some changes.
> ___
> 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 Minutes 2020-02-26

[Dave Cridland]

On Wed, 4 Mar 2020 at 10:23, Daniel Gultsch  wrote:

> Am So., 1. März 2020 um 01:14 Uhr schrieb Tedd Sterr <
> teddst...@outlook.com>:
> > 4b) Advance XEP-0198 (Stream Management) -
> https://xmpp.org/extensions/xep-0198.html
> > Georg is unsure, but it's doing its job, expect for the unclear resume
> host connection mechanism.
> > Dave noted a comment on s2s, possibly from MattJ, which he has yet to
> consider, but s2s is under-specified at best.
> > Jonas doesn't think it's possible to move forward if there are zero s2s
> implementations; Dave doesn't think any were explicitly mentioned, which
> would itself be a procedural reason for not advancing.
> > Zash mentions that mod_smacks for Prosody does support XEP-0198 in s2s,
> though not resumption, and it's disabled by default - Dave thinks it's
> unclear what resumption would do for s2s.
> >
> > Jonas: [on-list] (yet to catch up on the thread)
> > Daniel: -1 (people have brought up valid, but fixable, concerns)
> > Zash: -1 (haven't read that thread yet)
> > Dave: -1 (lack of clarity on s2s implementations)
> > Georg: -1
>
>
> Do we have a way forward with this that isn’t just ignoring it?
> Are any of the authors who are still active in the community (looking
> at you Matt and Dave) willing to incorporate whatever the consensus is
> on how to proceed?
>
>
Sure.


> Do we want to eliminate s2s from the XEP?
>
>
I don't know. Mostly, I don't know if anyone implements it. I'm pretty sure
M-Link does on S2S, because I think I put it there - but whether anything
else does I don't know.


> Are server developers interested in implementing 198 s2s?
>
>
I might, in Metre. But I'd definitely only do acks, not resumption - I
don't think there's any value on resumption for S2S.


> Personally I would hope for the latter. But I’m not a server
> developer; Maybe it's more complicated or unnecessary as it seems.
>
>
> >
> > 4c) Advance XEP-0368 (SRV records for XMPP over TLS) -
> https://xmpp.org/extensions/xep-0368.html
> > Travis Burtrum promised to make some changes to XEP-0368, mostly
> clerical, and changing a SHOULD to a MAY.
> >
> > Jonas: -1 (changes need to be made)
> > Georg: -1 (liked the proposed wording)
> > Zash: [on-list]
> > Daniel: [on-list] (not caught up on that)
>
> -1. I think there is consensus for some changes.
> ___
> 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] Call for Experience: XEP-0198: Stream Management

[JC Brand]

On 26.02.20 12:25, Andrew Nenakhov wrote:

пт, 21 февр. 2020 г. в 14:33, JC Brand :

I have worked on deployments where Converse.js is integrated together with 
roster and presences and/or MUC presences and where pages are regularly 
reloaded (i.e. not a single-page app).

Btw, I assume you use a strophe.js library. Personally, I didn't dive
into details, but my web developers who work with  web version of
Xabber, which also uses this library currenlty, complained to me about
SM implementation there. It was something about it counting stanzas
differently than ejabberd does. It was over a year ago so I am not
very sharp on details, but I can ask them for a clarification, email
me directly pls if you want it.


Converse uses Strophe.js but doesn't use any Strophe plugins (which 
includes SM).


Converse has its own independent SM module.

BTW, I know that someone from Jitsi was working on the Strophe SM plugin 
recently.



-JC

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

Re: [Standards] LAST CALL: XEP-0398 (User Avatar to vCard-Based Avatars Conversion)

[Kevin Smith]

On 4 Mar 2020, at 10:00, Daniel Gultsch  wrote:
> 
> I’d like to get some more feedback (from more than 2 people) before I
> rewrite vast parts of the XEP.
> The XEP talks a lot about copy pasting one avatar to the other instead
> of feeding them both from the same data storage.
> To the user both approaches might provide very similar results but
> when it comes to the access model there is an important difference:
> One checks the access model once on publication; the other one
> essentially modifies 0153 in that it imposes the access model of 84 on
> 0153 on every read. While I totally get how and why this is desirable
> I think there is no denying in that it changes how 0153 work without
> telling users who only know about 0153. I find that controversial and
> would like to have more feedback on that.

I think the concerns raised about ACL are valid. If I configure a pubsub node 
to be private and publish something to it, it likely shouldn’t then appear in 
another public data store. So at a minimum not doing the propagation from 
pubsub to vcard if the node has been configured to not be public would seem to 
make sense to me.

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

Re: [Standards] Council Minutes 2020-02-26

[Kevin Smith]

On 4 Mar 2020, at 10:22, Daniel Gultsch  wrote:
> 
> Am So., 1. März 2020 um 01:14 Uhr schrieb Tedd Sterr :
>> 4b) Advance XEP-0198 (Stream Management) - 
>> https://xmpp.org/extensions/xep-0198.html
>> Georg is unsure, but it's doing its job, expect for the unclear resume host 
>> connection mechanism.
>> Dave noted a comment on s2s, possibly from MattJ, which he has yet to 
>> consider, but s2s is under-specified at best.
>> Jonas doesn't think it's possible to move forward if there are zero s2s 
>> implementations; Dave doesn't think any were explicitly mentioned, which 
>> would itself be a procedural reason for not advancing.
>> Zash mentions that mod_smacks for Prosody does support XEP-0198 in s2s, 
>> though not resumption, and it's disabled by default - Dave thinks it's 
>> unclear what resumption would do for s2s.
>> 
>> Jonas: [on-list] (yet to catch up on the thread)
>> Daniel: -1 (people have brought up valid, but fixable, concerns)
>> Zash: -1 (haven't read that thread yet)
>> Dave: -1 (lack of clarity on s2s implementations)
>> Georg: -1
> 
> 
> Do we have a way forward with this that isn’t just ignoring it?
> Are any of the authors who are still active in the community (looking
> at you Matt and Dave) willing to incorporate whatever the consensus is
> on how to proceed?
> 
> Do we want to eliminate s2s from the XEP?
> 
> Are server developers interested in implementing 198 s2s?
> 
> Personally I would hope for the latter. But I’m not a server
> developer; Maybe it's more complicated or unnecessary as it seems.

FWIW, M-Link implements 198 acks (but not resumption) for X2X sessions (I don’t 
remember if we do S2S or not - I *think* we do, and if we don’t we’ll end up 
doing so).

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

Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts

[Kevin Smith]

On 3 Mar 2020, at 17:45, Jonas Schäfer (XSF Editor)  wrote:
> 
> The XEP Editor would like to Call for Experience with XEP-0184 before
> presenting it to the Council for advancing it to Final status.
> 
> 
> During the Call for Experience, please answer the following questions:
> 
> 1. What software has XEP-0184 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.

Swift (GPL)

> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0184? If so, please describe the problems and, if
> possible, suggested solutions.

No. Kinda. The rules distinguishing between Bare/Full JID and assuming that 
full JID messages will only go to the addressed JID are somewhat out of place 
in the modern world and could do with a rethink, methinks. The ’SHOULD NOT’ in 
particular seems inappropriate.

The ‘must not ack from an archive’ is also somewhat out of place in a world 
where clients are disabling offline messages in favour of fetching from an 
archive.

In general, I think 184’s interactions with modern routing/message handling 
haven’t been considered and implementing 184 as-is might be unfortunate.

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

Re: [Standards] XEP-0184: Message Delivery Receipts and XEP-0333: Chat Markers

[Kevin Smith]

At the risk of AOLing, I think I agree with pretty much everything Marvin says 
here.

/K

> On 4 Mar 2020, at 11:45, Marvin W  wrote:
> 
> XEP-0184 is doing one job, that is to notify the sender when a message
> was delivered to the recipient's client. That's literally what the title
> is. While in setups with MAM and SM, far less messages get lost, the
> pure specification of XMPP does not guarantee every message to be
> delivered to the recipient's client, so it makes sense to have this
> information per message. XEP-0184 does this job perfectly well, so I
> wonder why you are saying it only does half the job.
> 
> XEP-0184 is widely implemented both in receiving and sending.
> 
> The only thing I personally don't like about XEP-0184 is that it doesn't
> allow to ack several messages with one message. I do agree though that
> the overhead of using multiple messages isn't that much and in most
> cases you don't have a bunch of messages to ack at the same time.
> 
> ---
> 
> In contrast XEP-0333 serves a mostly different purpose: it notifies the
> sender only of the last received/displayed/acknowledged message. This
> means it can not be used as a means to verify that a specific message
> was received, displayed or acknowledged. It also is weird that it
> specifies that you have to interact with a message to acknowledge it,
> but then only the last message that was acknowledged is transferred, so
> the user interaction with previous messages can actually get lost. In
> general, I'd say that XEP-0333 is way less mature then XEP-0184 and
> serves an unclear set of goals.
> 
> The XEP-0333 displayed feature is supported by many clients. The
> received feature of XEP-0333 is not often implemented in sending and
> sometimes also has very weird behavior in receiving (e.g. contrary to
> the XEP, only the message that was referenced in the received marker is
> marked as received, not all previous messages - which makes sense
> because XEP-0333 does not give any guarantee for previous messages, yet
> claims to). The acknowledged feature also seems to be barely used (also
> because it is questionable how to realize it UI wise).
> 
> Therefor deprecating/obsoleting XEP-0184 seems like a very bad idea to
> me, I'd rather remove the received/acknowledged feature from XEP-0333
> and rename it to read markers (which is the only part most implement
> anyway) so we don't have an overlap in features and people stop claiming
> that XEP-0184 might be obsoleted by XEP-0333. Also reducing the feature
> set of XEP-0333 could make it easier to advance to Draft/Final state.
> 
> On 3/4/20 11:04 AM, Andrew Nenakhov wrote:
>> But seriously, 0184 is a half-baked XEP that does only half the job
>> done. XMPP is currently extremely bloated with redundant XEPs, and
>> instead of trimming it down and streamlining it, you suggest setting
>> an already obsolete XEP in stone. If anyone here is worried about
>> bringing this protocol to the masses, it's not the way to go.
>> 
> ___
> 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-0184: Message Delivery Receipts and XEP-0333: Chat Markers

[Marvin W]

XEP-0184 is doing one job, that is to notify the sender when a message
was delivered to the recipient's client. That's literally what the title
is. While in setups with MAM and SM, far less messages get lost, the
pure specification of XMPP does not guarantee every message to be
delivered to the recipient's client, so it makes sense to have this
information per message. XEP-0184 does this job perfectly well, so I
wonder why you are saying it only does half the job.

XEP-0184 is widely implemented both in receiving and sending.

The only thing I personally don't like about XEP-0184 is that it doesn't
allow to ack several messages with one message. I do agree though that
the overhead of using multiple messages isn't that much and in most
cases you don't have a bunch of messages to ack at the same time.

---

In contrast XEP-0333 serves a mostly different purpose: it notifies the
sender only of the last received/displayed/acknowledged message. This
means it can not be used as a means to verify that a specific message
was received, displayed or acknowledged. It also is weird that it
specifies that you have to interact with a message to acknowledge it,
but then only the last message that was acknowledged is transferred, so
the user interaction with previous messages can actually get lost. In
general, I'd say that XEP-0333 is way less mature then XEP-0184 and
serves an unclear set of goals.

The XEP-0333 displayed feature is supported by many clients. The
received feature of XEP-0333 is not often implemented in sending and
sometimes also has very weird behavior in receiving (e.g. contrary to
the XEP, only the message that was referenced in the received marker is
marked as received, not all previous messages - which makes sense
because XEP-0333 does not give any guarantee for previous messages, yet
claims to). The acknowledged feature also seems to be barely used (also
because it is questionable how to realize it UI wise).

Therefor deprecating/obsoleting XEP-0184 seems like a very bad idea to
me, I'd rather remove the received/acknowledged feature from XEP-0333
and rename it to read markers (which is the only part most implement
anyway) so we don't have an overlap in features and people stop claiming
that XEP-0184 might be obsoleted by XEP-0333. Also reducing the feature
set of XEP-0333 could make it easier to advance to Draft/Final state.

On 3/4/20 11:04 AM, Andrew Nenakhov wrote:
> But seriously, 0184 is a half-baked XEP that does only half the job
> done. XMPP is currently extremely bloated with redundant XEPs, and
> instead of trimming it down and streamlining it, you suggest setting
> an already obsolete XEP in stone. If anyone here is worried about
> bringing this protocol to the masses, it's not the way to go.
> 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-02-26

[Daniel Gultsch]

Am So., 1. März 2020 um 01:14 Uhr schrieb Tedd Sterr :
> 4b) Advance XEP-0198 (Stream Management) - 
> https://xmpp.org/extensions/xep-0198.html
> Georg is unsure, but it's doing its job, expect for the unclear resume host 
> connection mechanism.
> Dave noted a comment on s2s, possibly from MattJ, which he has yet to 
> consider, but s2s is under-specified at best.
> Jonas doesn't think it's possible to move forward if there are zero s2s 
> implementations; Dave doesn't think any were explicitly mentioned, which 
> would itself be a procedural reason for not advancing.
> Zash mentions that mod_smacks for Prosody does support XEP-0198 in s2s, 
> though not resumption, and it's disabled by default - Dave thinks it's 
> unclear what resumption would do for s2s.
>
> Jonas: [on-list] (yet to catch up on the thread)
> Daniel: -1 (people have brought up valid, but fixable, concerns)
> Zash: -1 (haven't read that thread yet)
> Dave: -1 (lack of clarity on s2s implementations)
> Georg: -1


Do we have a way forward with this that isn’t just ignoring it?
Are any of the authors who are still active in the community (looking
at you Matt and Dave) willing to incorporate whatever the consensus is
on how to proceed?

Do we want to eliminate s2s from the XEP?

Are server developers interested in implementing 198 s2s?

Personally I would hope for the latter. But I’m not a server
developer; Maybe it's more complicated or unnecessary as it seems.


>
> 4c) Advance XEP-0368 (SRV records for XMPP over TLS) - 
> https://xmpp.org/extensions/xep-0368.html
> Travis Burtrum promised to make some changes to XEP-0368, mostly clerical, 
> and changing a SHOULD to a MAY.
>
> Jonas: -1 (changes need to be made)
> Georg: -1 (liked the proposed wording)
> Zash: [on-list]
> Daniel: [on-list] (not caught up on that)

-1. I think there is consensus for some changes.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS

[Daniel Gultsch]

Am Di., 11. Feb. 2020 um 16:31 Uhr schrieb Jonas Schäfer :
>
> The XEP Editor would like to Call for Experience with XEP-0368 before
> presenting it to the Council for advancing it to Final status.
>
>
> During the Call for Experience, please answer the following questions:
>
> 1. What software has XEP-0368 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.

Among the implementations that I control Conversations has implemented that.
(Originally written by the author of the XEP)

Also the Compliance Tester picks up on that. (Not sure if that counts :-) )

> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0368? If so, please describe the problems and, if
> possible, suggested solutions.

To set the ALPN I think the original implementation had to resort to
reflections because Java 8 didn’t have a public interface for that.
For the compliance tester I had to bump from Java 8 to Java 11 or so
and to this date it's the only reason the compliance tester doesn’t
run on Java 8.

I don’t think it should stop the XEP from going forward though; but you asked…

>
> 3. Is the text of XEP-0368 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.
>
> If you have any comments about advancing XEP-0368 from Draft to Final,
> please provide them by the close of business on 2020-02-25. After the
> Call for Experience, this XEP might undergo revisions to address
> feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.


I agree with what seems to be the consensus in the rest of the thread:
The XEP should not mandate the mixing. (Even though Conversations does
that)

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

Re: [Standards] Call for Experience: XEP-0184: Message Delivery Receipts

[Andrew Nenakhov]

ср, 4 мар. 2020 г. в 11:10, Philipp Hörist :
>
>
>
> Am Di., 3. März 2020 um 21:19 Uhr schrieb Andrew Nenakhov 
> :
>>
>>
>> I think this XEP should be obsoleted in favour of XEP-0333 Chat
>> Markers, which does all that XEP-0184 does, plus something more.
> Why would someone depreacte a spec that is implemented in nearly every client 
> in existence, for something that does, best case, exactly the same?

That's what I was asking when learned about deprecating XEP-0071.

But seriously, 0184 is a half-baked XEP that does only half the job
done. XMPP is currently extremely bloated with redundant XEPs, and
instead of trimming it down and streamlining it, you suggest setting
an already obsolete XEP in stone. If anyone here is worried about
bringing this protocol to the masses, it's not the way to go.

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0398 (User Avatar to vCard-Based Avatars Conversion)

[Daniel Gultsch]

I’d like to get some more feedback (from more than 2 people) before I
rewrite vast parts of the XEP.
The XEP talks a lot about copy pasting one avatar to the other instead
of feeding them both from the same data storage.
To the user both approaches might provide very similar results but
when it comes to the access model there is an important difference:
One checks the access model once on publication; the other one
essentially modifies 0153 in that it imposes the access model of 84 on
0153 on every read. While I totally get how and why this is desirable
I think there is no denying in that it changes how 0153 work without
telling users who only know about 0153. I find that controversial and
would like to have more feedback on that.

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