On Mittwoch, 6. Dezember 2017 18:58:32 CET Kevin Smith wrote: > On 6 Dec 2017, at 18:47, Sam Whited <s...@samwhited.com> wrote: > > On Wed, Dec 6, 2017, at 12:12, Kevin Smith wrote: > >> I think 49 needs to be in there for servers - it’s widely needed to make > >> clients useful. > > > > What is actually using this today other than a few legacy clients that > > haven't updated their bookmarks implementation? I do not think we should > > be recommending this going forward, so I didn't include it. > > We discussed in Council today the need to add a note to 48 that even new > implementations need to do 49 if they want to interop. I’d be interested in > knowing what the proportion of clients using pubsub compared to 49 is, but > I think it’s that more or less everyone still does 49.
Yes. Poezio, JabberCat (a client I’m working on), and even Conversations (at least read-only) still do 49. I don’t know about Dino. Anyone not supporting 49 and forcing things on PEP would fail massively, not only because of lack of support in a popular server, but also because clients may not pick it up, at all. (Not to mention all the "legacy" clients many people still use.) > >> 84 is listed as N/A for server, but I think it’s possible for a server > >> satisfying its requirements to not meet the requirements of 84 (someone > >> tell me if I’m wrong). > > > > What requirements? That definitely sounds like a problem if so. > > It needs multiple items per node, doesn’t it? Maybe I misremember, but we > should check. No, that’s not true. I think that’s something some folks (including me) wanted to go for, but it’s a slow progress of updating specs (see the most-recent XEP-0060 update) and implementations (particularly the PubSub side of things). > >> I’m not sure about listing resumption as needed for IM - as discussed > >> earlier in the MUC I don’t think it’s the real solution to that problem, > >> but it’s not a hill for me to die on. > > > > I disagree; this is essential for a good mobile experience. > > I was noting about the IM table, not the Mobile table (I think the same is > true for mobile that it’s not the /right/ solution, but I think it’s the > best we’ve currently got). I’m pretty sure that resumption isn’t going to go away, even in the long term. I wouldn’t want to have a storm of inbound presence and PEP (on_sub_and_presence) notifications on each failover on mobile. (The discussion in the MUC, if we’re thinking about the same, mostly concerned messages.) But this is probably a discussion for another time, and not for this LC. > >> and I think 153 needs > >> to be in there to reflect current reality - I wouldn’t recommend anyone > >> not implement it, even though we might think 84 is a better direction. > > > > Would it be satisfactory to say that read-only 0153 satisfies the > > requirement? I feel strongly that we shouldn't include 153, but the > > compromise Conversations made where it's read-only seems like a good one > > to me. > > My reading of the current situation is that if you only write to 84, you > will have very low interop. I could be wrong. You are right. We only implemented '84 in JabberCat, and it is quite bad, you essentially only get avatars from Conversations and Movim. And from Conversations, you only get them if you support image/webp, despite the XEP mandating at least one image/png variant (this is a separate real-world issue we need to address at some point.) kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
