[Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

Kevin Smith kevin.smith at isode.com
Wed Dec 6 18:58:32 UTC 2017


On 6 Dec 2017, at 18:47, Sam Whited <sam at samwhited.com> wrote:
> 
> Thanks for the feedback; I'll address some of it below, however, I think
> we should leave any changes for next year since the last call ended
> before this feedback was submitted.

Ah, but Council term ended so we have a new LC don’t we? :)

> 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.

>> 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.

>> 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).

> 
>> 48 makes 223 support implicit, but I think making it explicit would be
>> sensible.
> 
> Agreed.
> 
>> On footnote 11, this feels a bit of a cop-out. I feel the barrier for a
>> server should be higher than just ‘does 114’ in order to claim to support
>> 60-on-a-jid and 45.
> 
> I agree, but this footnote was already in there from past years so I
> left it alone. I'd love to relitigate this next year though.
> 
>> 57 seems a fairly core requirement that’s missing
> 
> Wrong number or is this something clients actually use? I don't think
> I've ever seen 57 and it's retracted.

54, no idea how I typod that, sorry.

> 
>> 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.

/K

>> I think 220 should probably be in there, even today, but hills, dying,
>> etc.
> 
> I'm not sure about this one, it doesn't seem necessary to me and it's
> probably not a direction we want to recommend going forward, but I
> wouldn't mind hearing from server developers and operators about it.
> 
>> I think suggesting full 60 on a user JID would be a very sensible thing
>> to do, in the modern world, but maybe better delayed for next year.
> 
> Agreed.
> 
> 
> —Sam
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________



More information about the Standards mailing list