[Standards] Council Minutes 2020-05-27
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 . 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
> 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.
: 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...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards