Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Dave Cridland]

On 20 January 2016 at 16:09, Peter Saint-Andre  wrote:

> On 1/19/16 9:49 AM, XMPP Extensions Editor wrote:
>
>> 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
>>
>
> My opinion is that if we want to support text/markdown, let's write a spec
> for that.
>
> There is a large list of text media types here:
>
> http://www.iana.org/assignments/media-types/media-types.xhtml#text
>
> I don't think it's a great idea to support any arbitrary text format
> (sgml, troff, raptorfec, csv, etc.), in part because each one has different
> security implications.
>
>
I'd be happy to have a whitelist of media types we suggest.


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

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Peter Saint-Andre]

On 1/19/16 9:49 AM, XMPP Extensions Editor wrote:

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


My opinion is that if we want to support text/markdown, let's write a 
spec for that.


There is a large list of text media types here:

http://www.iana.org/assignments/media-types/media-types.xhtml#text

I don't think it's a great idea to support any arbitrary text format 
(sgml, troff, raptorfec, csv, etc.), in part because each one has 
different security implications.


Peter

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

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Matthew Wild]

On 19 January 2016 at 16:49, XMPP Extensions Editor  wrote:
> 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
>
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.

I just voted against this proposal today, for the following reasons:

 - I'm not seeing any consensus in favour of this approach on the
list. Mostly only concerns.

 - I don't believe the problem the specification was written to solve
(including markdown *and* "plaintext" in a single message) is a
problem that needs solving. We already have a standard for
communicating plaintext content () and a standard for
communicating formatted content (XHTML-IM). I don't think we need any
more.

 - Adding more (optionally rendered) representations of the content
into a single message increases bandwidth. There is no mechanism to
discover what content types the recipient will understand. Such a
discovery mechanism, if added, would also be complicated (e.g. the
recipient may not be online).

 - Adding more (optionally rendered) representations of the content of
a message introduces further complication into knowing which version
of the content any particular client will display, potentially leading
to security concerns.

 - Unclear interaction with XEPs that encrypt the plaintext content in
a message.

 - Unclear interaction with archiving (e.g. which version(s) of the
content should be archived?)

 - Unclear interaction with xml:lang

 - Not interoperable with existing clients (some of which already
support markdown, and *are* interoperable with other existing clients,
thanks to  and XHTML-IM), it is just causing fragmentation and
yet another markup format for clients to implement if they want to
render formatted messages.

 - Finally, regarding Markdown specifically, many noted there is no
commonly-accepted standard, so a simple mimetype would not be enough
to unambiguously describe the format of the content in this case
anyway.

Regards,
Matthew
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Ashley Ward]

> On 19 Jan 2016, at 19:41, Matthieu Rakotojaona 
>  wrote:
> 
> It looks like this XEP hands messages that have a single 
> element, but the RFC says you can have multiple elements, each with
> its own xml:lang. Is it expected that this works only with single
>  elements ?
> 
> Side question: are there uses of multiple  elements with
> different xml:lang ?

Very good point. If there are multiple  elements in different languages 
then they should be in the same format, so I assume the type hint should apply 
to all of them. Maybe update the EXP to clarify?

—
Ash

smime.p7s
Description: S/MIME cryptographic signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Goffi]

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
>  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  element - which is in my opinion a 
bad practice, but this is an other topic -, so addind a  element 
will make it appears in clear.
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Goffi]

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  
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
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Justin Karneges]

On Tue, Jan 19, 2016, at 08:49 AM, XMPP Extensions Editor wrote:
> 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

Cool! Is it just coincidence that this looks like part of my old
proposal?
http://mail.jabber.org/pipermail/standards/2013-January/027003.html

Now it just needs content-encoding. ;)

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

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Thijs Alkemade]

> On 19 jan. 2016, at 17:49, XMPP Extensions Editor  wrote:
> 
> 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
> 
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.

The Security Considerations section of this proto-XEP is missing, though
XEP-0001 §12 requires every XEP to have one. For this XEP, I don't think an
empty section would suffice because it really should discuss consistency.

Should a client try protect the user from receiving a message that contains
multiple content types with completely different meanings? If I'm reading back
the log of a conversation on a different device, can I trust that the messages
I see there are the same messages I actually responded to? The conversation
could be completely different on two clients supporting different sets of
content types. This can be abused quite easily to scam people or to create
incriminating logs.

Yes, we already have the same problem with XEP-0071, but with only two
different formats it is still manageable to fix it, for example by deprecating
the use of . If we add the ability to add many different
representations to a message then consistency will be a lost cause forever.

Regards,
Thijs




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Matthieu Rakotojaona]

It looks like this XEP hands messages that have a single 
element, but the RFC says you can have multiple elements, each with
its own xml:lang. Is it expected that this works only with single
 elements ?

Side question: are there uses of multiple  elements with
different xml:lang ?

On Tue, Jan 19, 2016 at 5:49 PM, XMPP Extensions Editor  wrote:
> 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
>
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___



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

[Standards] Proposed XMPP Extension: Content Types in Messages

[XMPP Extensions Editor]

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

The XMPP Council will decide in the next two weeks whether to accept this 
proposal as an official XEP.

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