Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Dave Cridland]

On 8 March 2018 at 15:58, Sam Whited  wrote:
> I thought we were specifically voting to obsolete (because this was about 
> wide spread security issues); the minutes do say "deprecate", but we kept 
> mixing up the terminology. I hate our process.
>

PRs to XEP-0001 welcome. :-)

> Can other council members weigh in with what they thought we were doing?
>

The agenda, minutes and chat transcripts all say explicitly
"Deprecate", with no mention of Obsoletion.

> —Sam
>
> On Thu, Mar 8, 2018, at 05:15, Jonas Wielicki wrote:
>> On Donnerstag, 8. März 2018 10:38:55 CET Kozlov Konstantin wrote:
>> > Hello!
>> >
>> > 08.03.2018, 12:18, "Dave Cridland" :
>> > The personal choice of Council was to deprecate XHTML-IM based on
>> > these facts. The previous Council decided to ensure there were
>> > alternates for XHTML-IM use-cases instead of deprecating.
>>
>> This was an editors mistake. The Council voted to Deprecate, not to Obsolete.
>> I rectified the issue and I’m going to send out an email when the update is
>> live on the website. Thanks for bringing this up and sorry for the
>> inconvenience.
>>
>> kind regards,
>> Jonas
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>> Email had 1 attachment:
>> + signature.asc
>>   1k (application/pgp-signature)
>
>
> --
> Sam Whited
> s...@samwhited.com
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Sam Whited]

I thought we were specifically voting to obsolete (because this was about wide 
spread security issues); the minutes do say "deprecate", but we kept mixing up 
the terminology. I hate our process.

Can other council members weigh in with what they thought we were doing?

—Sam

On Thu, Mar 8, 2018, at 05:15, Jonas Wielicki wrote:
> On Donnerstag, 8. März 2018 10:38:55 CET Kozlov Konstantin wrote:
> > Hello!
> >  
> > 08.03.2018, 12:18, "Dave Cridland" :
> > The personal choice of Council was to deprecate XHTML-IM based on
> > these facts. The previous Council decided to ensure there were
> > alternates for XHTML-IM use-cases instead of deprecating.
> 
> This was an editors mistake. The Council voted to Deprecate, not to Obsolete. 
> I rectified the issue and I’m going to send out an email when the update is 
> live on the website. Thanks for bringing this up and sorry for the 
> inconvenience.
> 
> kind regards,
> Jonas
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)


-- 
Sam Whited
s...@samwhited.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Kozlov Konstantin]

Hello! 08.03.2018, 14:15, "Jonas Wielicki" :On Donnerstag, 8. März 2018 10:38:55 CET Kozlov Konstantin wrote: Hello! 08.03.2018, 12:18, "Dave Cridland" : The personal choice of Council was to deprecate XHTML-IM based on these facts. The previous Council decided to ensure there were alternates for XHTML-IM use-cases instead of deprecating.This was an editors mistake. The Council voted to Deprecate, not to Obsolete.I rectified the issue and I’m going to send out an email when the update islive on the website. Thanks for bringing this up and sorry for theinconvenience.In that case it's all right. While XEP is deprecated, I may keep develop its implementation until XEP-0394 become pwerful enogh to substitute it. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Jonas Wielicki]

On Donnerstag, 8. März 2018 10:38:55 CET Kozlov Konstantin wrote:
> Hello!
>  
> 08.03.2018, 12:18, "Dave Cridland" :
> The personal choice of Council was to deprecate XHTML-IM based on
> these facts. The previous Council decided to ensure there were
> alternates for XHTML-IM use-cases instead of deprecating.

This was an editors mistake. The Council voted to Deprecate, not to Obsolete. 
I rectified the issue and I’m going to send out an email when the update is 
live on the website. Thanks for bringing this up and sorry for the 
inconvenience.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Dave Cridland]

On 8 March 2018 at 10:54, Manuel Rubio  wrote:
> Hi guys,
>
> I usually only read to understand and learn but sometimes I head up and
> freak out with some decision. I usually read RFC and when a new one is
> released it supersedes, deprecates or obsoletes another one. But, the status
> of that RFC usually is definitive. Obviously it's definitive until a better
> one is released (as Descartes always said there are nothing definitive only
> temporal until we can find a better solution/theory/explanation).
>

It's not an RFC it's a XEP, and the procedures are different.

If this were an RFC, we'd be designating it "Historical".

> In this case I can see you are putting "obsolete" to XEP-0071 and it's
> intended there are a new proposal better on the table... where? XEP-0071 has
> no explanation about why it was obsoleted only a vague description "Per a
> vote of the XMPP Council, advanced to Obsolete". I wanted to know "why".
>

Summarized in this thread and intensively discussed in Council and on this list.

> And more important, if the XEP-0071 is obsoleted because XEP-0393 is
> there... why XEP-0393 is experimental? I'm not pretty sure but looks like
> you are suggesting to use something experimental instead of something it was
> working for years. If XEP-0393 is the reason because XEP-0071 is obsoleted,
> I think it's fair enough to advance the state from experimental to something
> different for XEP-0393, IMO.
>

No.

XEP-0071 is obsoleted on its own merits. The other XEPs merely show
there could be a viable alternative.

XEP-0393 will be advanced on its own merits later.

> Last thing, what's the usual flow for the states? I cannot find information
> here: https://xmpp.org/extensions/ ; there are only the possibility to
> filter based on those states but not information about what means each one
> or even how it could be advanced from one to another.

XEP-0001.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Manuel Rubio]

Hi guys,

I usually only read to understand and learn but sometimes I head up and 
freak out with some decision. I usually read RFC and when a new one is 
released it supersedes, deprecates or obsoletes another one. But, the 
status of that RFC usually is definitive. Obviously it's definitive 
until a better one is released (as Descartes always said there are 
nothing definitive only temporal until we can find a better 
solution/theory/explanation).


In this case I can see you are putting "obsolete" to XEP-0071 and it's 
intended there are a new proposal better on the table... where? XEP-0071 
has no explanation about why it was obsoleted only a vague description 
"Per a vote of the XMPP Council, advanced to Obsolete". I wanted to know 
"why".


And more important, if the XEP-0071 is obsoleted because XEP-0393 is 
there... why XEP-0393 is experimental? I'm not pretty sure but looks 
like you are suggesting to use something experimental instead of 
something it was working for years. If XEP-0393 is the reason because 
XEP-0071 is obsoleted, I think it's fair enough to advance the state 
from experimental to something different for XEP-0393, IMO.


Last thing, what's the usual flow for the states? I cannot find 
information here: https://xmpp.org/extensions/ ; there are only the 
possibility to filter based on those states but not information about 
what means each one or even how it could be advanced from one to 
another.


Thanks.
Manuel Rubio.

El 2018-03-08 10:57, Goffi escribió:

Le mercredi 7 mars 2018, 19:21:45 CET Kozlov Konstantin a écrit :

Thank you for your reply. Yes, I know about those two. As for 
XEP-0394, I

feel so bad the XEP idea, so I don't even want to discuss the XEP
itself.


Out of curiousity, what do you dislike in this XEP? I actually find the 
idea
really good, it's a clean separation between content and style, which 
means
that there is not need to send a text version as we have too with 
XHTML-IM.
XEP-0393 on the other hand is totally mixing style and content, that's 
why

I really dislike it.

Goffi


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Kozlov Konstantin]

Hello! 08.03.2018, 12:58, "Goffi" :Le mercredi 7 mars 2018, 19:21:45 CET Kozlov Konstantin a écrit :  Thank you for your reply. Yes, I know about those two. As for XEP-0394, I feel so bad the XEP idea, so I don't even want to discuss the XEP itself.Out of curiousity, what do you dislike in this XEP? I actually find the ideareally good, it's a clean separation between content and style, which meansthat there is not need to send a text version as we have too with XHTML-IM.XEP-0393 on the other hand is totally mixing style and content, that's whyI really dislike it.I'm really sorry.  I mixed up those two. The name of those XEPs (Markup and Styling) are confusing me.So, I really dislike XEP-0393 and I find XEP-0394 interesting and worth further development. Sorry once again for confusing other subscribers of this mailing list. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Goffi]

Le mercredi 7 mars 2018, 19:21:45 CET Kozlov Konstantin a écrit :

> Thank you for your reply. Yes, I know about those two. As for XEP-0394, I
> feel so bad the XEP idea, so I don't even want to discuss the XEP
> itself. 

Out of curiousity, what do you dislike in this XEP? I actually find the idea 
really good, it's a clean separation between content and style, which means 
that there is not need to send a text version as we have too with XHTML-IM.
XEP-0393 on the other hand is totally mixing style and content, that's why 
I really dislike it.

Goffi


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Kozlov Konstantin]

Hello! 08.03.2018, 12:18, "Dave Cridland" :The personal choice of Council was to deprecate XHTML-IM based onthese facts. The previous Council decided to ensure there werealternates for XHTML-IM use-cases instead of deprecating.Deprecating is not a serious problem. The probleb is that they are obsoleted if instead of deprecating. And that sounds really bad. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Dave Cridland]

On 8 March 2018 at 08:34, Evgeny Khramtsov  wrote:
> TL;DR: I conclude that the only argument is that XML is a bit more
> secure (with possibly less possible holes, lol). So, as I thought, this
> is purely a matter of personal choice and not a technical decision,
> that's why we debated about it so much.

It can be both, you know.

XML's security problems are fairly limited (essentially, entities and
escaping). Because they're highly generic, XML parsers have had
support for preventing the various entities attacks at a low level for
some time, and since these attacks are generic, they're soluble at the
XML parser level.

Embedding user-generated [X]HTML into a web UI is also a well-known
security issue, and the advice from web-devs is simply not to do it -
there are a few libraries to try and make this safe, but the browsers
don't include these, and instead you need to do iframe embedding. As
HTML and CSS standards mutate, you need your library to be constantly
maintained to ensure that security issues stay closed, or be highly
restrictive in what is allowed (and essentially parse the XHTML into
an intermediate state and reassemble only the safe parts).

Whilst there are no extant and ongoing issues with XML, the issues in
XHTML-IM keep cropping up in new web clients.

Those are the technical facts.

The personal choice of Council was to deprecate XHTML-IM based on
these facts. The previous Council decided to ensure there were
alternates for XHTML-IM use-cases instead of deprecating.

These are personal choices.

As a side-note, this doesn't have any impact on embedding XHTML into
XMPP. Just that if what you want is snazzy-looking IM messages, it's
not a sensible way to do it.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Kozlov Konstantin]

Hello! 08.03.2018, 10:52, "Jonas Wielicki" :In contrast to XML, XHTML-IM is a custom thing which needs to be re-implemented in ~every client. Well-known XML libraries exist for mostlanguages (even if they only FFI to libxml2 or libexpat).According to my experience, building a XHTML processor using an existing XML parser is a trivial task. It doesn't took a lot of time for me to build such processor using QtXML/QDomDocument framework. With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Evgeny Khramtsov]

Thu, 08 Mar 2018 08:51:26 +0100
Jonas Wielicki  wrote:

> How many XMPP clients have you seen which were owned by Billion
> Laughs (which uses entities which are explicitly forbidden in RFC6120
> and trivial to turn off in all XML parsers I’ve seen so far) compared
> to the amount of XMPP clients Sam has found which were vulnerable to
> XHTML-IM XSS attacks? I think the comparison might not hold up, but
> I’m open for data. (Likewise for any other XML vulnerability.)

I don't know, I didn't count and not going to count them for you. Kids
these days might not remember, but Billion Laughs was pretty serious
vulnerability despite being well known with several implementations
affected. So new XMPP implementations might be vulnerable just easily.

> Also, XML vulnerabilities are both well-known and easy to test
> against (in the sense: it is easy to write an automated test which
> ensures that code is not vulnerable).

And where are those tests?

> I don’t think that’s so trivial with XSS attacks. During the
> XHTML-IM debate I learnt that even CSS can be an XSS vector (in some
> really broken implementations

Sure, and were there debates of possible XML security holes? So the
comparison is not quite fair. Not to mention that it's a logical
fallacy to speculate about possible vulnerabilities: one can say
everything might have security issues.

> In contrast to XML, XHTML-IM is a custom thing which needs to be re-
> implemented in ~every client. Well-known XML libraries exist for most 
> languages (even if they only FFI to libxml2 or libexpat).

Well-known XML libraries didn't protect from Billion Laughs attack. Not
sure what this argument is for.

TL;DR: I conclude that the only argument is that XML is a bit more
secure (with possibly less possible holes, lol). So, as I thought, this
is purely a matter of personal choice and not a technical decision,
that's why we debated about it so much.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Jonas Wielicki]

On Donnerstag, 8. März 2018 07:54:04 CET Evgeny Khramtsov wrote:
> Wed, 07 Mar 2018 21:33:13 +0300
> 
> Kozlov Konstantin  wrote:
> > So, the only reason to obsolete the XEP is not the XEP itself, but
> > bad implementations?
> 
> Yes. This is kinda religion among some Council members that if a
> technology can be misused then it should be deprecated. Their religion
> is, however, quite picky: there is a well-known list of security
> problems in XML (including the famous billion laughs attack), but they
> don't consider to get rid of XML.

How many XMPP clients have you seen which were owned by Billion Laughs (which 
uses entities which are explicitly forbidden in RFC6120 and trivial to turn 
off in all XML parsers I’ve seen so far) compared to the amount of XMPP 
clients Sam has found which were vulnerable to XHTML-IM XSS attacks? I think 
the comparison might not hold up, but I’m open for data. (Likewise for any 
other XML vulnerability.)

Maybe you could make a server module which stress-tests clients against that 
type of input. I’d be interested, but that’s off-topic to the XHTML-IM 
discussion.

Also, XML vulnerabilities are both well-known and easy to test against (in the 
sense: it is easy to write an automated test which ensures that code is not 
vulnerable). I don’t think that’s so trivial with XSS attacks. During the 
XHTML-IM debate I learnt that even CSS can be an XSS vector (in some really 
broken implementations; not to mention possible privacy implications by using 
background: url(…) etc.), at which point I concluded for myself that XHTML-IM 
as it is is irresponsible because sanitization is so complex that nobody is 
going to do it completely, and those who are will most likely get it wrong. 
(My proposal to have someone create a reference implementation of a sanitizer 
in a language which would be most-reusable in this domain (probably JS) and 
have it professionally reviewed unfortunately didn’t gain traction.)

In contrast to XML, XHTML-IM is a custom thing which needs to be re-
implemented in ~every client. Well-known XML libraries exist for most 
languages (even if they only FFI to libxml2 or libexpat).

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Paul Schaub]

Am 07.03.2018 um 19:18 schrieb Jonas Wielicki:
> I started to work on 
> [XEP-0394] (Message Markup) which intends to do a bit more, with a more 
> flexible approach. Note that I intend to overhaul XEP-0394 and I don’t know 
> of 
> any implementations.

FYI: I implemented it for Smack :)

https://github.com/igniterealtime/Smack/commit/a729a7c43b9d3a8bd09744916d718675b6a54a80

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Evgeny Khramtsov]

Wed, 07 Mar 2018 21:33:13 +0300
Kozlov Konstantin  wrote:

> So, the only reason to obsolete the XEP is not the XEP itself, but
> bad implementations?

Yes. This is kinda religion among some Council members that if a
technology can be misused then it should be deprecated. Their religion
is, however, quite picky: there is a well-known list of security
problems in XML (including the famous billion laughs attack), but they
don't consider to get rid of XML.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Sam Whited]

On Wed, Mar 7, 2018, at 12:33, Kozlov Konstantin wrote:
> So, the only reason to obsolete the XEP is not the XEP itself, but bad
> implementations? 

In a sense. Fixing the existing broken implementation doesn't fix the 
underlying problem though. It's more about the fact that any tiny mistake when 
implementing the XEP will likely create a security issue (as we have seen in 
the real world). Because even if you implement a whitelist (which is 
technically secure) it is a whitelist on top of a very large, complicated 
system with many different attack vectors. If you make any sort of mistake when 
implementing that whitelist, you potentially expose the underlying complicated 
system (XHTML). If we can build something simpler on top of a less complicated 
system, we can hopefully avoid some of these issues.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Kozlov Konstantin]

Hello! 07.03.2018, 19:19, "Guus der Kinderen" :Primarily due to security concerns. There's a lot of discussion available in the mail archive. This is a good place to start: https://mail.jabber.org/pipermail/standards/2017-October/033546.html Thank you! I just read the message. I never thought that there are implementations of the XEP, which allow to execute scripts.I'm sure my implementaion do not.So, the only reason to obsolete the XEP is not the XEP itself, but bad implementations? With my best regards,Konstantin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Kozlov Konstantin]

Hello! 07.03.2018, 21:20, "Jonas Wielicki" :As for an replacement, it depends on your use-case. There’s [XEP-0393](Message Styling) which should cover many IM use-cases. I started to work on[XEP-0394] (Message Markup) which intends to do a bit more, with a moreflexible approach. Note that I intend to overhaul XEP-0394 and I don’t know ofany implementations. XEP-0393 is implemented in a few clients already (I knowof Conversations and yaxim).kind regards,Jonas   [1]: https://mail.jabber.org/pipermail/standards/2017-October/033546.html   [2]: https://mail.jabber.org/pipermail/standards/2017-October/033596.html   [3]: https://mail.jabber.org/pipermail/standards/2017-October/033702.html   [4]: https://mail.jabber.org/pipermail/standards/2018-February/034302.html   [5]: http://logs.xmpp.org/council/2018-02-14/#16:03:14Thanx, I'll investigate those discussions. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Kozlov Konstantin]

Hello! 07.03.2018, 19:18, "Jonas Wielicki" :On 7 March 2018 17:13:26 CET, Kozlov Konstantin  wrote:___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org___cf. https://github.com/xsf/xeps/pull/594#issuecomment-369839060Thank you for your reply. Yes, I know about those two. As for XEP-0394, I feel so bad the XEP idea, so I don't even want to discuss the XEP itself.As for XEP-0393, yes, I feel it really interesting, but... see my reply to Sam. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Jonas Wielicki]

Due to popular request, I’m going to re-post the reply I gave earlier on 
GitHub:

The core reason is that it caused quite a few XSS vulnerabilities. There are 
lengthy threads on the standars mailing list:

* starting with Security issues with XHTML-IM (again) [1]
* some discussion on replacement in Rich(er) text in IM vs XHTML docs [2] 
* collection of replacement requirements in Formatting Use Cases [3]

And much more. I recommend you to browse the archives if you really want to 
get the whole picture. The XMPP standards community has discussed this at 
length and the final ruling of the council is in the respective meeting 
minutes: Council Minutes 2018-02-14 [4] and MUC logs of the meeting [5]. 

---

As for an replacement, it depends on your use-case. There’s [XEP-0393] 
(Message Styling) which should cover many IM use-cases. I started to work on 
[XEP-0394] (Message Markup) which intends to do a bit more, with a more 
flexible approach. Note that I intend to overhaul XEP-0394 and I don’t know of 
any implementations. XEP-0393 is implemented in a few clients already (I know 
of Conversations and yaxim).


kind regards,
Jonas

   [1]: https://mail.jabber.org/pipermail/standards/2017-October/033546.html
   [2]: https://mail.jabber.org/pipermail/standards/2017-October/033596.html
   [3]: https://mail.jabber.org/pipermail/standards/2017-October/033702.html
   [4]: https://mail.jabber.org/pipermail/standards/2018-February/034302.html
   [5]: http://logs.xmpp.org/council/2018-02-14/#16:03:14
   [XEP-0393]: https://xmpp.org/extensions/xep-0393.html
   [XEP-0394]: https://xmpp.org/extensions/xep-0394.html


signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Kozlov Konstantin]

 Hello! 07.03.2018, 19:55, "Sam Whited" :On Wed, Mar 7, 2018, at 10:13, Kozlov Konstantin wrote: Yes, this XEP has its disadvantages, but almos all of modern clients do implement it and there is no XEP right now, which can substitute it.TL;DR — almost all of modern clients that implement it implement it in an insecure manner (which is not the XEPs fault, but it is apparently hard for developers to implement it correctly, especially in web clients in my experience).Thank you for your reply. Unfortunately, I missed the discussions about security issues in XHTML-IM implementations. So, please give me the link to overview of such issues if it exists. As a devoleper of a client whish imlements the XEP, I wonder if my implementation also have such issues.For most clients, https://xmpp.org/extensions/xep-0393.html serves as a good enough replacement (especially when paired with https://xmpp.org/extensions/xep-0066.html or https://xmpp.org/extensions/xep-0385.html for media).For clients where that is not good enough they won't drop XHTML-IM support over night and we can have a discussion about how to support them if and when they come forward.As for XEP-0393, as I said before, it's really interesting but it has some weak points and I guess we need to start discussing the way fill the gaps, before a lot of implementations appeared.The most important things IMHO is lack of links and embedded images. You may attach links to message with XEP-0066, but thats not it. Sometimes it's much better when parts if text are clickable, so the message is not overloaded with redundant information.About embedded images... As a developer of an XMPP client, I have some UX of my app for some years and according to it, 90% of using XHTML-IM is embedding images into messages. Of course, XEP-0385 allows to send an image in a separate message, but embedding images into text is more flexible and allows user to compose more fancy messages to express their ideas better.And the second weak point is duplicated markers in lists. I'm sure extra markers should be removed anyhow. I have some ideas how to develop XEP-0393 to implement embedded images and links and how to remove markers from the list. If anyone's interested, let's discuss them. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Sam Whited]

On Wed, Mar 7, 2018, at 10:13, Kozlov Konstantin wrote:
> Yes, this XEP has its disadvantages, but almos all of modern clients do
> implement it and there is no XEP right now, which can substitute it. 

TL;DR — almost all of modern clients that implement it implement it in an 
insecure manner (which is not the XEPs fault, but it is apparently hard for 
developers to implement it correctly, especially in web clients in my 
experience).

For most clients, https://xmpp.org/extensions/xep-0393.html serves as a good 
enough replacement (especially when paired with 
https://xmpp.org/extensions/xep-0066.html or 
https://xmpp.org/extensions/xep-0385.html for media).
For clients where that is not good enough they won't drop XHTML-IM support over 
night and we can have a discussion about how to support them if and when they 
come forward.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Guus der Kinderen]

Primarily due to security concerns. There's a lot of discussion available
in the mail archive. This is a good place to start:
https://mail.jabber.org/pipermail/standards/2017-October/033546.html

On 7 March 2018 at 17:13, Kozlov Konstantin  wrote:

> I wonder, why this one was obsoleted?
> Yes, this XEP has its disadvantages, but almos all of modern clients do
> implement it and there is no XEP right now, which can substitute it.
>
>
>
> 28.02.2018, 21:24, "Jonas Wielicki (XSF Editor)" :
>
> Version 1.5.3 of XEP-0071 (XHTML-IM) has been released.
>
> Abstract:
> This specification defines an XHTML 1.0 Integration Set for use in
> exchanging instant messages that contain lightweight text markup. The
> protocol enables an XMPP entity to format a message using a small
> range of commonly-used HTML elements, attributes, and style properties
> that are suitable for use in instant messaging. The protocol also
> excludes HTML constructs that may introduce malware and other
> vulnerabilities (such as scripts and objects) for improved security.
>
> Changelog:
> Per a vote of the XMPP Council, advanced to Obsolete. (XEP Editor
> (ssw))
>
> URL: https://xmpp.org/extensions/xep-0071.html
>
> Note: The information in the XEP list at https://xmpp.org/extensions/
> is updated by a separate automated process and may be stale at the
> time this email is sent. The XEP documents linked herein are up-to-
> date.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[Kozlov Konstantin]

I wonder, why this one was obsoleted?Yes, this XEP has its disadvantages, but almos all of modern clients do implement it and there is no XEP right now, which can substitute it. 28.02.2018, 21:24, "Jonas Wielicki (XSF Editor)" :Version 1.5.3 of XEP-0071 (XHTML-IM) has been released.Abstract:This specification defines an XHTML 1.0 Integration Set for use inexchanging instant messages that contain lightweight text markup. Theprotocol enables an XMPP entity to format a message using a smallrange of commonly-used HTML elements, attributes, and style propertiesthat are suitable for use in instant messaging. The protocol alsoexcludes HTML constructs that may introduce malware and othervulnerabilities (such as scripts and objects) for improved security.Changelog:Per a vote of the XMPP Council, advanced to Obsolete. (XEP Editor(ssw))URL: https://xmpp.org/extensions/xep-0071.htmlNote: The information in the XEP list at https://xmpp.org/extensions/is updated by a separate automated process and may be stale at thetime this email is sent. The XEP documents linked herein are up-to-date.___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org__
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] OBSOLETED: XEP-0071 (XHTML-IM)

[XSF Editor]

Version 1.5.3 of XEP-0071 (XHTML-IM) has been released.

Abstract:
This specification defines an XHTML 1.0 Integration Set for use in
exchanging instant messages that contain lightweight text markup. The
protocol enables an XMPP entity to format a message using a small
range of commonly-used HTML elements, attributes, and style properties
that are suitable for use in instant messaging. The protocol also
excludes HTML constructs that may introduce malware and other
vulnerabilities (such as scripts and objects) for improved security.

Changelog:
Per a vote of the XMPP Council, advanced to Obsolete. (XEP Editor
(ssw))

URL: https://xmpp.org/extensions/xep-0071.html

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___