[Standards] Marking up messages with metadata and XEP-0071

Dave Cridland dave at cridland.net
Fri Apr 10 16:01:21 UTC 2015

On 9 April 2015 at 23:24, Ben Langfeld <ben at langfeld.me> wrote:

> On 9 April 2015 at 16:58, Florian Schmaus <flo at geekplace.eu> wrote:
>> On 09.04.2015 18:59, Ben Langfeld wrote:
>> > Florian, my concerns with your approach are twofold:
>> >
>> > 1. It is complicated and is not markup in the sense that is used by XML,
>> > HTML, SSML, etc. Being abstracted means a complicated association step.
>> Yep, it's more complicated then just adding another attribute to an
>> element surrounding text.
>> Not sure what's the issue with it being not markup. In my eyes that's an
>> advantage here.
> It is, conceptually, metadata for marking up part of the text body. I'm
> not sure what the motivation is for avoiding this idea.
It does mean you can have a plain-text body, which is quite nice; but I
think one could decide that any jid-like "word" was in fact a jid and fetch
vCard data for it, rendering it as the name, etc - with false positives for
email, and so on, of course.

In other words, I might type:

I talked to Romeo today.

My client might note "Romeo" matched one of my contacts, and suggest I
meant "Romeo Montague". I affirm, and the message as sent is:

I talked to romeo at montague.example today.

A smart(ish) client then get vCard data and renders:

I talked to [Romeo Montague] today.

Rendering Romeo Montague as a hyperlink, perhaps with a tooltip (or
similar) with the avatar, jid, and so on.

This uses no markup (and no additional inlined metadata), and no
negotiation is required, but it's reliant on heuristics. Sending:

Romeo's email address is romeo at hotmail.example

... might confuse things; luckily it must be very rare that an email
address has an identical-looking jid used by someone else.

On the plus side, caching would work well here.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150410/942bd975/attachment.html>

More information about the Standards mailing list