[Standards] form field types: text-multi vs list-multi with <validate><open/></validate>

Kevin Smith kevin.smith at isode.com
Wed May 13 13:01:23 UTC 2020


I think you’ve carefully (and silently) snipped out the most relevant half of my message, so I repeat what I said before.

1) I think we can not reasonably update XEP-0004 to change the meaning of text-multi at this point (and, as I said, it is not clear to me if anyone is suggesting that or not).
2) If XEPs want to change the meaning of text-multi for specific cases in a negotiated scope, they can do so.

i.e. (2)-> if MAM uses text-multi differently, in MAM-namespaced queries, it’s reasonable to do so. This is consistent with what XEP-0122 does in allowing <open/> to change the semantics for list-multi/list-single that were defined in XEP-0004. It would be functionally equivalent to saying that MAM uses a text-multi field with one id per line.


> On 13 May 2020, at 13:50, Florian Schmaus <flo at geekplace.eu> wrote:
> On 5/13/20 1:50 PM, Kevin Smith wrote:
>> On 13 May 2020, at 03:40, Peter Saint-Andre <stpeter at mozilla.com> wrote:
>>> <snip/>
>>> We might want to face reality
>>> and allow text-multi to treat each line as semantically independent.
>> Sadly, I don’t think it would just be ‘facing reality’ to say that text-multi isn’t multi-line text - there are implementations (every library I’ve worked with, I think) that treats text-multi as a multi-line string (i.e. in support of what xep4 requires).
> As soon as such a library where to implement e.g. PubSub collection
> nodes, it has to expose the individual values of a text-multi field in a
> robust way. And it is not like doing so would mean that you have to
> loose support for what xep4 requires.
> Because surely those libraries could be easily extended to expose the
> text-multi values, in addition to a single multi-line string, as a list
> of strings.
>> I am sympathetic to the argument that we’ve gotten into a mess, but I don’t think getting out of it (given that 4 is Final) would be as simple as xep 4 changing semantics for text-multi - it’s not clear to me if that’s what being suggested, but if it is I think it would be painful.
> I do not see where we change the semantics of text-multi here.
> XMPP (and protocols in general) often gets criticized for being
> over-engineerd and complex. And, while I do not like those who scream
> "over-engineerd and complex" every two seconds, this discussion appears
> to be a prime example what can go wrong.
> We have currently two options to carry multiple values from A to B in
> xep4 data forms:
> - one that requires one XEP
>  text-multi: xep4
> - another one that requires *two* XEPs
>  list-multi + <open/>, xep4 + xep122
> Obviously text-multi, requiring only one XEP, is desirable. In fact, it
> so natural that existing XEPs and ProtoXEPs in inbox/ use it for exact
> that case.
> Yet, there are attempts to argument that text-multi can not be used
> because of some implementations do not allow for it. But I fail to see
> how that can be an argument: implementations can be adjusted.
> Furthermore, it appears *trivial* to extend those existing
> implementations to allow for it. And that would not even break backwards
> compatibility, and hence does not even need to be negotiated.
> Fields of the type text-multi contain as a list of textual values. Even
> if the initial motivation was to allow for portable multi-line strings,
> I do not see any reason why we should not continue to use it to
> transport multiple textual values (e.g., the IDs of the MAM messages we
> want to retrieve).
> MAM currently is a shining star of a reasonably well-designed and simple
> protocol. I hope we keep it that way.
> - Florian
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

More information about the Standards mailing list