[Standards] XEP-0163: Notify after directed presence

[Maxime Buquet]

Hi standards,


I found about this issue while working on the OMEMO implementation in
poezio (that should be available soon(tm)), but I guess this can be
applied to other things. The issue goes as follows:

- Start encrypted chat with non-contact recipient.
  At this point, my OMEMO code will fetch devicelist and bundles via
  PEP.
- Recipient then updates his OMEMO status (adds a device, removes a
  devices from the devicelist)
- ???
  I am not aware of changes as I am not being notified through PEP
  because of not being a contact. I continue encrypting same as I was
  before the changes.


One obvious answer is to add the recipient as contact, but this might
not always fly.

Asking quickly in jdev@ [0], I was suggested to use directed presences,
and [even if it might not be specified yet?] it would make sense if I
now received PEP notifications for items with an access_model of "open".

Thoughts?


Happy Hacking!


[0]: https://logs.xmpp.org/jdev/2019-08-24#2019-08-24-bf845f259b5e8576

-- 
Maxime “pep” Buquet


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

Re: [Standards] SNI Encryption in TLS

[Jonas Schäfer]

On Dienstag, 20. August 2019 11:30:16 CEST Dave Cridland wrote:
> Hi folks,
> 
> This one may be of interest to this community; it's in Last Call at the
> IETF currently:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

Last time I checked this conflicted with SRV records, or at least it was 
totally unclear how it would work together with SRV records.

I am currently extremely short on mental resources, and I’m also not familiar 
with IETF process. If someone could take another look and potentially raise 
concerns over there? That’d be super-great of you.

Thanks and Sorry.
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] OBSOLETED: XEP-0387 (XMPP Compliance Suites 2018)

[XSF Editor]

Version 1.0.0 of XEP-0387 (XMPP Compliance Suites 2018) has been
released.

Abstract:
This document defines XMPP protocol compliance levels.

Changelog:
Move to Draft as per Council vote on 2018-01-24. (XEP Editor (jwi))

URL: https://xmpp.org/extensions/xep-0387.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] NEW: XEP-0421 (Anonymous unique occupant identifiers for MUCs)

[XSF Editor]

Version 0.1.0 of XEP-0421 (Anonymous unique occupant identifiers for
MUCs) has been released.

Abstract:
This specification defines a method that allows clients to identify a
MUC participant across reconnects and renames. It thus prevents
impersonification of anonymous users.

Changelog:
Accepted by vote of Council on 2019-07-17. (XEP Editor (jsc))

URL: https://xmpp.org/extensions/xep-0421.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] UPDATED: XEP-0368 (SRV records for XMPP over TLS)

[XSF Editor]

Version 1.1.0 of XEP-0368 (SRV records for XMPP over TLS) has been
released.

Abstract:
This specification defines a procedure to look up xmpps-client/xmpps-
server SRV records (for direct TLS connections) in addition to xmpp-
client/xmpp-server and mix weights/priorities.

Changelog:
Describe how to fall back if _xmpps-server/_xmpps-client records
cannot be found. (jsc)

URL: https://xmpp.org/extensions/xep-0368.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] UPDATED: XEP-0414 (Cryptographic Hash Function Recommendations for XMPP)

[XSF Editor]

Version 0.3.0 of XEP-0414 (Cryptographic Hash Function Recommendations
for XMPP) has been released.

Abstract:
This document provides recommendations for the use of cryptographic
hash functions in XMPP protocol extensions.

Changelog:
Remove dangling reference to analysis of hash function use in existing
XMPP extensions. It can still be found in XEP-0300, version 0.5
().
Thanks to Dennis Baurichter for pointing this out. (jsc)

URL: https://xmpp.org/extensions/xep-0414.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
___

Re: [Standards] Council Voting Summary 2019-08-18

[Jonas Schäfer]

On Mittwoch, 21. August 2019 01:06:07 CEST Dave Cridland wrote:
> On Tue, 20 Aug 2019 at 16:58, Jonas Schäfer  wrote:
> > On Dienstag, 20. August 2019 10:34:22 CEST Dave Cridland wrote:
> > > > *PR #808 - XEP-0045: Add Tags configuration and metadata* -
> > > > https://github.com/xsf/xeps/pull/808
> > > > Dave: [pending]
> > > > Georg: [on-list]
> > > > Jonas: +1
> > > > Kev: [pending]
> > > > Link: [on-list]
> > > 
> > > I think I'm -1 on this. I don't think that having tags is a bad idea, in
> > > and of itself, but I'm concerned with adding more stuff to XEP-0045.
> > > 
> > > In general, I think that tagging in this "dumb" way is probably never
> > 
> > going
> > 
> > > to be enough, and a more considered approach might be better.
> > > 
> > > For what it's worth, I'm open to having my mind changed on this.
> > 
> > As someone in favour of this, what do you consider "dumb" about this?
> 
> Dumb as in the tags are simply "there", and therefore only of use to an
> external search engine, really.
> 
> So things you can't do are filter by tag on a disco#items search, say, or
> assign some internal meaning to specific tags for state management or
> workflow or something.
> 
> Put another way, I'm not sure this gives anything to build upon - it's just
> a field of strings, and there's no indication of semantics or intended use
> here. I can implement it easily enough from the spec, but I have no idea
> how to use it beyond "put some strings here".
> 
> Quite a lot of '45 is like this already, and I'd rather not make things
> worse.

Fair enough. Do you have a proposal with which we could provide a similar UX 
to users?

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___