[Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)

Georg Lukas georg at op-co.de
Wed Nov 6 13:43:54 UTC 2019

* Kevin Smith <kevin.smith at isode.com> [2019-11-06 12:24]:
> I think the addition of ’66 is well-intentioned, but jabber:x:oob <jabber:x:oob> is underspecified (it defines a syntax, but semantics are missing).

I agree, but nobody has written down the semantics yet, so there is no
place to link to. On the other hand, this approach seems to be so widely
used (despite me hating it), that it would be bad _not_ to tell
developers about it at all.

> I think 392 (consistent colours) is worth a mention, but not as a requirement at this stage.

Noted. There wass significant backlash against the addition of it, and
I'd like to have a brief discussion of it in today's Council. By now I
almost expect it to be moved into "Future" afterwards.

> I would rather see bookmarks2 as a requirement than 411, but don’t
> hugely care.

Good point. Bookmarks2 makes legacy-compat optional, but I would like to
mandate legacy support in the CS. Also I would like to see an explicit
statement that bookmarks added via Bookmarks2 become visible to
Private-XML and Legacy-PEP clients.

Also given that Bookmarks2 isn't widely supported yet, I have a better
feeling with it being in "Future".

> What does a client need to do to implement 411 though?

Nothing. I just was too lazy to split out the conversion into its own
dedicated table row.

> I think 286 (LTE mobile) is worth a mention, but how would one be
> compliant with it as a client or server?

By having the author read 286 ;-)

> I note that while requiring TLS is right, I suspect very few, if any,
> implementations follow 7590 (and by extension 7525).  It’s also
> inconsistent to require 7590 (and 7525) in core, but direct TLS (which
> 7525 would need) only in advanced.

I read your remark as "7525 makes Direct TLS mandatory", which I can not
see in the RFC. 7525 says that deployments SHOULD prefer "strict TLS"
(which is not really defined) over "dynamic upgrade" if supported.
Even when implying "Strict TLS" = "Direct TLS", we do not mandate
support for Direct TLS, so I don't see a violation here.

> My only note on this is that I think the introduction to “Future
> Development” isn’t right - these are protocols that aren’t ready to be
> required by the compliance suite, rather than not ready for production
> use.

I've updated the text accordingly; a rendered version of your and other
LC responses can be found at https://op-co.de/tmp/xep-0423.html

A PR will be generated shortly.

|| 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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191106/a2a887f6/attachment.sig>

More information about the Standards mailing list