[Standards] Proposed XMPP Extension: Content Types in Messages

Goffi goffi at goffi.org
Wed Jan 20 09:24:59 UTC 2016


Le mercredi 20 janvier 2016, 09:33:46 Goffi a écrit :
> Le mardi 19 janvier 2016, 16:49:22 XMPP Extensions Editor a écrit :
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> > 
> > Title: Content Types in Messages
> > 
> > Abstract: This specification describes a generic method whereby content in
> > messages can be tagged as having a specific Internet Content Type. It also
> > provides a method for sending the same content using different content
> > types, as a fall-back mechanism when communicating between clients having
> > different content type support.
> > 
> > URL: http://xmpp.org/extensions/inbox/content-types.html
> 
> Hello,
> 
> I still think this XEP is a false good idea, as I said in last week
> discussion. Here are the main reasons:
> 
> 	- there are already a couple of projects using markdown through the
> standardized XHTML-IM. With this XEP, we'll have some markdown in a
> <content> element, some converted in XHTML-IM, which one should I use?
> 
> 	- mardown is not a standard, and the only tentative to standardize it
> (CommonMark) is not popular for the moment (not even sure of its status at
> all)
> 
> 	- even if a standard was there, there are and will probably always be
> different flavours. In other terms, every client will tend to have slightly
> different rendering, in the opposition of what XMPP currently offers or try
> to offers (same thing on each screen in the same order).
> 
> 	- beside markdown, other syntaxes will be used, each client having its
> favorite one. This will bring more fragmentation
> 
> 	- today we have 2 types contents: plain text and rich (XHTML-IM). I don't
> see any reason to add on extra one, or at least a syntax which translate
> trivially to XHTML is not a good reason to add a new content for me.
> 
> 	- XHTML/XHTML-IM being XML, so using the same kind of parser that what is
> already used for XMPP, it seems the natural option for rich content. If the
> goal of all this is to edit markdown, we do convert XHTML => markdown, and
> it's working reasonably well, specially for the limited set of elements that
> we have in XHTML-IM
> 
> 	- I would rather see markdown put as text content (without hint or
> anything), than having extra elements with any possible syntax.
> 
> 
> In addition I wonder what is the point of this? For instant messaging, it's
> not common to edit text, or with last message correction (and client can
> keep the last message original syntax in cache trivially). Why not doing
> the conversion markdown => XHTML-IM client side before sending the message?
> 
> For blogging, it's more natural to use XHTML, and anyway this XEP doesn't
> cover the case (blogging use PubSub, not messages).
> 
> 
> Regards
> Goffi


just thinking about an other issue: current encryption method (OTR and soon to 
be released OMEMO) encrypt only the <body/> element - which is in my opinion a 
bad practice, but this is an other topic -, so addind a <content/> element 
will make it appears in clear.


More information about the Standards mailing list