[Standards] Council Minutes 2020-05-27

Jonas Schäfer jonas at wielicki.name
Mon Jun 1 14:10:16 UTC 2020

On Montag, 1. Juni 2020 15:28:40 CEST Maxime Buquet wrote:
> 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.

I expect us to Deprecate / Obsolete the spec once we have a replacement with a 
proper wire format for conveying markup. If you feel strongly about this 
situation, the best way to fix it is to make a proposal which replaces the 
versatility of XHTML-IM (with some accessibility (colours) fixes). You’ll find 
lots of inspiration in the threads from the Eternal October 2017 where the 
Styling discussion first came up [1]. I expect this task to be about as fun as 
trying to get a Compliance Suite to Draft.

Then we can Deprecate or Obsolete '393 and move the input format 
recommendations to a UX-centric location (either as "Implementation Note" in 
XHTML-IM-NG or a third-party resource).

With the proposed additions, the document does indeed define a (albeit ugly) 
wire format to be used within XMPP. The <styling/> element clearly signals 
that a specific (albeit ugly) wire format (inside <body/>) for marking up text 
is used, which has a rather clearly defined effect. This is useful for non-IM 
and non-human-operated entities, too.

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

The default in *current* implementations of the (un-namespace-versioned) '393 
is indeed. With the wording proposed by Dave, implementations "MAY" choose 
styling as default, but they don’t have to. Implementations can very well 
choose to offer this optionally and/or have unstyled by default if the 
coverage of the <styled/> tag is widespread enough.

kind regards,

   [1]: Some links:

- Original thread by Sam: 
- Rich text thread by Dave:
- Formatting Use Cases thread by Sam:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200601/c2ce4e1f/attachment.sig>

More information about the Standards mailing list