Hello Ashley, and others.
>> I?m sure this must have been discussed and dismissed before, but would
>> adding a some kind of content/MIME type attribute to the body help at all?
>> That way a client can stick markdown or yaml or whatever the flavour of the
>> day is into the body, give it a type, and then the receiving client can then
>> decide whether it can/wants to render that type nicely or just display it as
>> plain text?
>
> I suppose the problem is then that it might encourage people to stick
> non-textual content into the body too - base64 encoded binaries, etc.
>
> Maybe having a separate ?rich body? element might work, which can contain
> markdown, yaml, rich text, etc?
>
> Just some thoughts...
I like this idea.
Would the council be in favour of accepting a protoXEP according these lines?
Defining an element <content type="text/...">...</content> which can be used as
a complement to the normal text body. It could be limited to top-level types
"text", to avoid the problem Ashley mentions. (Or leave that as a security
note. There might be cases where other types might be of interest as well.) In
this way there's a standardized way to encapsulate internet content (of
relatively small size) into a message.
>
> Further to my previous message, maybe a ?content type hint? extension:
>
> <message ...>
> <body>
> # Some markdown or whatever
> Yeah!
> </body>
> <content-type xmlns=?xmpp:contenttype:0?>text/x-markdown</content-type>
> </message>
>
> It would be a very simple extension, could piggy-back off MIME content types,
> and could be safely ignored by clients.
I was thinking about this solution as well (i.e. just a flag in the message
that the body message had a specific content type). But I would prefer the
content being a supplement of a plain text body (as in the XHTML-case). In that
case, there's Always a simple text version available for clients not
understanding the content type used.
Best regards,
Peter Waher
_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
