> On 7 Jan 2016, at 12:44, Peter Waher <[email protected]> wrote:
> 
> Hello all
>  
> > If anything we should define a small microformat that looks good
> > formatted or in plain text (which could just be a specific Markdown
> > flavor minus the raw HTML stuff) and mandate that all clients that
> > support the spec use that one format.
>  
> Why define something new when there's a format that people like, know and 
> want to use?
>  
> Furthermore, leaving the format out of the XEP allows standardization of the 
> format to be done in other forums.

Agreed. And there is a standardisation effort for Markdown which will help the 
interoperability issue.

> 
> > 
> > So perhaps both approaches have their use cases? I don't fundamentally
> > object to either, but including multiple renderings in a
> > multipart/alternative style all the time just for improved handing of
> > *this* seems overkill.
> > 
>  
> What about an approach that allows both?
>  
> Say we create a new element <content type='...'/> that we send with the 
> message. If it's empty, it could be considered a hint regarding the format of 
> the message body. If it is non-empty, it contains an alternative, a formatted 
> version of the plain text message body.

I think allowing alternate content renditions could be opening up a whole can 
of worms. We already have the body for plain text and XHTML-IM for rich text. 
If the plain text version happens to be structured then I think hinting as to 
the underlying format is useful (and I am definitely emphasising that it’s a 
hint to make the point that it can be safely ignored).

Some kind of type hinting solves the issue that sparked this thread, and I like 
the fact that it’s potentially not limited to markdown - you could imagine a 
system sending data in a yaml format for example, which is both human and 
machine readable. It’s also nice and simple.

—
Ash

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to