[Standards] Council Minutes 2020-05-27

Maxime Buquet pep at bouah.net
Mon Jun 1 13:28:40 UTC 2020

On 2020/06/01, Jonas Schäfer wrote:
> [..]
> First off, as Dave mentioned already (and as "everyone" will already know), 
> arguably this is deployed very widely. And not because of '393, specifically, 
> but because people have been using these types of metamarkers for so long 
> already that nobody could possibly trace it down to a single source. In a way, 
> they are similar to quotation marks; they’ve become part of an additional 
> grammar used by many people throughout the internet.
> There are "cultural dialects" (e.g. the various markdown flavors), but there 
> is basic compatibility. Pinning down the XMPP dialect of this is a good` 
> thing™.

I disagree. I think this is a bad idea and that we shouldn't endorse
this as the XSF. XMPP is not a product line, it's a protocol. What
specific sigils are being used (as input format) shouldn't be enforced
at the protocol level.

> However, we need a way forward which will not have to rely on transmitting 
> these markers on the wire. And we also need to be able to deal with entities 
> which send text which is strongly not intended to be formatted based on those 
> markers.
> With the proposed mandatory opt-in and opt-out solution, we get both of that. 
> I *hope* that clients which unambiguously support '393 will start to add the 
> opt-in so that the default behaviour (in absence of any marker) can move back 
> from "styled" to "unstyled". In addition, should we ever have to iterate on 
> this document (either in a new XEP or in this thing while it’s in draft), we 
> now have a wire format element of which the namespace can be bumped.

> On Montag, 1. Juni 2020 10:23:37 CEST Dave Cridland wrote:
> > [..]
> > If we have a hint and (approximately) the text above in the specification,
> > is this enough to make people... if not actually happy, at least willing to
> > grudgingly accept the document?

The proposed changes are indeed better than 393 as is for reasons jonas

These changes de facto make the XEP an opt-out XEP though, as long as
the default is to interpret <body/> for markup.

Maxime “pep” Buquet
-------------- 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/20200601/8e5ba333/attachment.sig>

More information about the Standards mailing list