> On 21 Mar 2016, at 14:14, Dave Cridland <d...@cridland.net> wrote: > > > > On 21 March 2016 at 14:06, Kevin Smith <kevin.sm...@isode.com> wrote: > > > On 21 Mar 2016, at 11:48, Daniel Gultsch <dan...@gultsch.de> wrote: > > > > An update to the 'arbitrary attributes' feature request. Even more > > important than the before mentioned content-type, content-length and so > > forth are probably description and a thumbnail. Information which can be > > extracted for example by the means of open graph [1] meta tags from a lot > > of websites. > > > > This would allow for a proper link preview like slack, skype and so forth > > are doing. > > > > Kev: When questioning this. Is your concern that you don't want the > > attributes to be completely arbitrary? Do you want them to be well-defined? > > (Having a set list of like content-type, description, thumbnail, > > content-length and so forth?) Or would you rather not have attributes like > > this in this XEP at all? > > It’s a concern with the attributes being completely arbitrary (how does one > know which they need to support? discovery starts being a bit of a nuisance). > Non-abritrary data form elements could be reasonable - there’s still a > discoverability question, but it might be ok. Would you like to propose > something? I’ve not had the cycles since the summit to take much more of a > look at References. > > > I don't think there's any fundamental difference between arbitrary namespaced > child elements and a data form, except that a data form is more restrictive > and lends itself well to human interaction. I don't think we have any human > interaction here. So why a data form and not just allow namespaced child > elements, which can be ignored by recipients that don't understand them? > > (Note that I often dislike data forms in machine-driven protocol work, but > this case seems particularly unsuited).
This is entirely fair, and so do I. /K _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
