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

[Jonas Wielicki]

On Montag, 15. Januar 2018 09:47:28 CET Kevin Smith wrote:
> On 15 Jan 2018, at 09:31, Dave Cridland  wrote:
> > On 15 Jan 2018 07:02, "Jonas Wielicki"  > > wrote:> 
> > On Sonntag, 14. Januar 2018 13:53:53 CET Tedd Sterr wrote:
> > > As someone intending to develop a new modern client, I think a sensible
> > > (and useful) suggestion would be to add something along the lines of
> > > "Legacy Considerations." This could be inserted either as an additional
> > > row in each of the 2.x tables as necessary, or as a new section 2.5.
> > > That way 0084 can be recommended for new deployments, while
> > > acknowledging that 0153 is still widely used and advisable if you want
> > > any kind of compatibility (but that the latter isn't a recommendation
> > > in its own right.)
> > > 
> > > More broadly, this would open a space to mention other XEPs that aren't
> > > suggested but are still needed in reality for compatibility (e.g. 0049?)
> > 
> > I think this is a great way forward. Let’s recommend 153 & 49 for now
> > (because this is just like reality *is* ATM and it will be needed for
> > compat), and do what Tedd proposed for '19.
> > 
> > So you're saying "do nothing for now", and "do this for next year”?
> 
> I *think* Jonas is saying “Merge Kev’s PR for now” :)

Pretty much :-).

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
___

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

[Kevin Smith]

On 15 Jan 2018, at 09:31, Dave Cridland  wrote:
> On 15 Jan 2018 07:02, "Jonas Wielicki"  > wrote:
> On Sonntag, 14. Januar 2018 13:53:53 CET Tedd Sterr wrote:
> > As someone intending to develop a new modern client, I think a sensible (and
> > useful) suggestion would be to add something along the lines of "Legacy
> > Considerations." This could be inserted either as an additional row in each
> > of the 2.x tables as necessary, or as a new section 2.5. That way 0084 can
> > be recommended for new deployments, while acknowledging that 0153 is still
> > widely used and advisable if you want any kind of compatibility (but that
> > the latter isn't a recommendation in its own right.)
> >
> > More broadly, this would open a space to mention other XEPs that aren't
> > suggested but are still needed in reality for compatibility (e.g. 0049?)
> 
> I think this is a great way forward. Let’s recommend 153 & 49 for now (because
> this is just like reality *is* ATM and it will be needed for compat), and do
> what Tedd proposed for '19.
> 
> So you're saying "do nothing for now", and "do this for next year”?

I *think* Jonas is saying “Merge Kev’s PR for now” :)

/K

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Dave Cridland]

On 15 Jan 2018 07:02, "Jonas Wielicki"  wrote:

On Sonntag, 14. Januar 2018 13:53:53 CET Tedd Sterr wrote:
> As someone intending to develop a new modern client, I think a sensible
(and
> useful) suggestion would be to add something along the lines of "Legacy
> Considerations." This could be inserted either as an additional row in
each
> of the 2.x tables as necessary, or as a new section 2.5. That way 0084 can
> be recommended for new deployments, while acknowledging that 0153 is still
> widely used and advisable if you want any kind of compatibility (but that
> the latter isn't a recommendation in its own right.)
>
> More broadly, this would open a space to mention other XEPs that aren't
> suggested but are still needed in reality for compatibility (e.g. 0049?)

I think this is a great way forward. Let’s recommend 153 & 49 for now
(because
this is just like reality *is* ATM and it will be needed for compat), and do
what Tedd proposed for '19.


So you're saying "do nothing for now", and "do this for next year"? In
which case I'm happy, especially with the first part.

I'm personally not even going to think about Compliance 2019 until 2018 is
out, and XEP-0387's last call is very much closed - it'd take something
catastrophic for me to reconsider that.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Jonas Wielicki]

On Sonntag, 14. Januar 2018 13:53:53 CET Tedd Sterr wrote:
> As someone intending to develop a new modern client, I think a sensible (and
> useful) suggestion would be to add something along the lines of "Legacy
> Considerations." This could be inserted either as an additional row in each
> of the 2.x tables as necessary, or as a new section 2.5. That way 0084 can
> be recommended for new deployments, while acknowledging that 0153 is still
> widely used and advisable if you want any kind of compatibility (but that
> the latter isn't a recommendation in its own right.)
> 
> More broadly, this would open a space to mention other XEPs that aren't
> suggested but are still needed in reality for compatibility (e.g. 0049?)

I think this is a great way forward. Let’s recommend 153 & 49 for now (because 
this is just like reality *is* ATM and it will be needed for compat), and do 
what Tedd proposed for '19.

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
___

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

[Tedd Sterr]

As someone intending to develop a new modern client, I think a sensible (and 
useful) suggestion would be to add something along the lines of "Legacy 
Considerations." This could be inserted either as an additional row in each of 
the 2.x tables as necessary, or as a new section 2.5. That way 0084 can be 
recommended for new deployments, while acknowledging that 0153 is still widely 
used and advisable if you want any kind of compatibility (but that the latter 
isn't a recommendation in its own right.)

More broadly, this would open a space to mention other XEPs that aren't 
suggested but are still needed in reality for compatibility (e.g. 0049?)

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Jonas Wielicki]

On Samstag, 13. Januar 2018 13:52:56 CET Evgeny Khramtsov wrote:
> You're right here. Seems like we need clients to be able to read
> vCards. However, for Private XML this is not needed at all.

Except that proper private PEP still lacks server support in many deployments. 
So again clients will need at least read (but most likely even write support) 
support for the foreseeable future.

That being said: I like what you did there with vcard-pep conversion. I think 
we can massively help migration (once server support is there) in the common 
private XML use-cases with a similar approach.

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
___

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

[Evgeny Khramtsov]

Sat, 13 Jan 2018 10:35:21 +0100
Jonas Wielicki  wrote:

> Can PEP-only clients somehow obtain avatars in MUCs?
> 
> If not, we need read-only 153 support in clients and servers no
> matter what.

You're right here. Seems like we need clients to be able to read
vCards. However, for Private XML this is not needed at all.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Jonas Wielicki]

On Samstag, 13. Januar 2018 09:35:42 CET Evgeny Khramtsov wrote:
> Fri, 12 Jan 2018 22:28:19 +
> 
> Kevin Smith  wrote:
> > I would almost certainly implement -49, in order to have interop with
> > the vast majority of currently deployed stuff, and as a server dev I
> > would absolutely certainly implement 49 - probably as one of the
> > first things I did.
> 
> I disagree about clients. Conversion between PEP and Private XML is
> even easier to implement in servers (than PEP and vCard avatars). And
> we need a XEP for it as well, btw :) So, I think this should be a
> MUST for modern servers to support all these XEP + conversion, when
> clients may only support PEP ones. Note that this approach also
> resolves the current situation with clients as long as servers get
> updated. IMHO.

Can PEP-only clients somehow obtain avatars in MUCs?

If not, we need read-only 153 support in clients and servers no matter what.

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
___

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

[Evgeny Khramtsov]

Fri, 12 Jan 2018 22:28:19 +
Kevin Smith  wrote:

> I would almost certainly implement -49, in order to have interop with
> the vast majority of currently deployed stuff, and as a server dev I
> would absolutely certainly implement 49 - probably as one of the
> first things I did.

I disagree about clients. Conversion between PEP and Private XML is
even easier to implement in servers (than PEP and vCard avatars). And
we need a XEP for it as well, btw :) So, I think this should be a
MUST for modern servers to support all these XEP + conversion, when
clients may only support PEP ones. Note that this approach also
resolves the current situation with clients as long as servers get
updated. IMHO.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Kevin Smith]

On 12 Jan 2018, at 09:04, Daniel Gultsch  wrote:
> I see the compliance suite as a list of XEPs that should be
> implemented if you want to create a modern day instant messenger.

Indeed, and I think this includes useful interop, not with long-abandoned 
software but with the current state of the network.

> There I oppose the idea of putting 0153, 0049 in there - especially if
> you consider this a guideline for someone implementing a new server it
> doesn't make any sense whatsoever to implement 0049.

But as a client dev, if I was implementing a new client, I would almost 
certainly implement -49, in order to have interop with the vast majority of 
currently deployed stuff, and as a server dev I would absolutely certainly 
implement 49 - probably as one of the first things I did. I don’t think -49 
here is a crude hack, but rather the state of the union.

> I am open to putting a slightly updated version of 0153 in the 2019
> compliance suite after we accepted the pep-vcard conversion and after
> we put (configurable) access control in front of 0153. That will give
> us the option of very carefully defining that 0153 is meant to be read
> only. But 0153 is not ready in that regard and should wait until 2019.

153 is pretty ready, it’s been widely deployed for years. We’d be doing devs a 
disservice if we told them that they should implement 84 and ignore 153, as 
they would soon find out that very few clients do 84, of those some don’t do it 
in an interoperable way, and the majority of deployed software does 153.

To this end, how about we include 153 in the listing as a piece of friendly 
advice only, and leave 84 as the MTI for compliance? I feel a dev would be 
rightly annoyed if they implemented 84 on the advice of 387, only to find most 
avatars unreadable.

/K

> 
> cheers
> Daniel
> 
> 2017-12-06 19:12 GMT+01:00 Kevin Smith :
>> On 1 Nov 2017, at 16:47, Jonas Wielicki  wrote:
>>> 
>>> On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote:
 This message constitutes notice of a Last Call for comments on
 XEP-0387.
 
 Abstract:
 This document defines XMPP protocol compliance levels for 2017.
 
 This Last Call begins today and shall end at the close of business on
 2017-10-30.
>>> 
>>> The Last Call is extended until 2017-11-15 on behalf of the XMPP Council.
>> 
>> Some somewhat late feedback on this:
>> 
>> I think 49 needs to be in there for servers - it’s widely needed to make 
>> clients useful.
>> 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).
>> 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.
>> 48 makes 223 support implicit, but I think making it explicit would be 
>> sensible.
>> 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. Not a hill for me to die on again, but - should we ask 
>> for more? Like a pointer to which components work with that server to make 
>> them compliant? Maybe that we’re not doing testing makes it irrelevant 
>> anyway.
>> 57 seems a fairly core requirement that’s missing, 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.
>> I think 220 should probably be in there, even today, but hills, dying, etc.
>> 
>> 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.
>> 
>> 
>> 
>> /K
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Daniel Gultsch]

I see the compliance suite as a list of XEPs that should be
implemented if you want to create a modern day instant messenger. It
is not a guideline on what crude hacks you have to do if you want to
be compatible with some random multi protocol messenger that hasn't
been updated in a decade.

There I oppose the idea of putting 0153, 0049 in there - especially if
you consider this a guideline for someone implementing a new server it
doesn't make any sense whatsoever to implement 0049.

I am open to putting a slightly updated version of 0153 in the 2019
compliance suite after we accepted the pep-vcard conversion and after
we put (configurable) access control in front of 0153. That will give
us the option of very carefully defining that 0153 is meant to be read
only. But 0153 is not ready in that regard and should wait until 2019.

cheers
Daniel

2017-12-06 19:12 GMT+01:00 Kevin Smith :
> On 1 Nov 2017, at 16:47, Jonas Wielicki  wrote:
>>
>> On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote:
>>> This message constitutes notice of a Last Call for comments on
>>> XEP-0387.
>>>
>>> Abstract:
>>> This document defines XMPP protocol compliance levels for 2017.
>>>
>>> This Last Call begins today and shall end at the close of business on
>>> 2017-10-30.
>>
>> The Last Call is extended until 2017-11-15 on behalf of the XMPP Council.
>
> Some somewhat late feedback on this:
>
> I think 49 needs to be in there for servers - it’s widely needed to make 
> clients useful.
> 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).
> 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.
> 48 makes 223 support implicit, but I think making it explicit would be 
> sensible.
> 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. Not a hill for me to die on again, but - should we ask 
> for more? Like a pointer to which components work with that server to make 
> them compliant? Maybe that we’re not doing testing makes it irrelevant anyway.
> 57 seems a fairly core requirement that’s missing, 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.
> I think 220 should probably be in there, even today, but hills, dying, etc.
>
> 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.
>
>
>
> /K
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Kevin Smith]

On 11 Dec 2017, at 17:23, Holger Weiß  wrote:
> 
> * Kevin Smith  [2017-12-11 17:16]:
>> On 11 Dec 2017, at 16:44, Holger Weiß  wrote:
>>> * Kevin Smith  [2017-12-11 15:34]:
 84 allows you to publish multiple versions of an avatar, each of which
 goes to its own item within the node, which would require multiple
 items.
>>> 
>>> It says the user "publishes avatar data for 'image/png' content-type to
>>> data node and optionally publishes other content-types to HTTP URLs."  I
>>> was assuming this was done precisely to avoid multiple items.
>> 
>> I think Example 10 is in conflict with that reading.
> 
> In example 10, a single 'metadata' item holding multiple 
> elements is published.  One of them references a 'data' item, the others
> reference HTTP URLs.

You’re entirely right.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Holger Weiß]

* Kevin Smith  [2017-12-11 17:16]:
> On 11 Dec 2017, at 16:44, Holger Weiß  wrote:
> > * Kevin Smith  [2017-12-11 15:34]:
> >> 84 allows you to publish multiple versions of an avatar, each of which
> >> goes to its own item within the node, which would require multiple
> >> items.
> > 
> > It says the user "publishes avatar data for 'image/png' content-type to
> > data node and optionally publishes other content-types to HTTP URLs."  I
> > was assuming this was done precisely to avoid multiple items.
> 
> I think Example 10 is in conflict with that reading.

In example 10, a single 'metadata' item holding multiple 
elements is published.  One of them references a 'data' item, the others
reference HTTP URLs.

Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Kevin Smith]

On 11 Dec 2017, at 16:44, Holger Weiß  wrote:
> 
> * Kevin Smith  [2017-12-11 15:34]:
>> 84 allows you to publish multiple versions of an avatar, each of which
>> goes to its own item within the node, which would require multiple
>> items.
> 
> It says the user "publishes avatar data for 'image/png' content-type to
> data node and optionally publishes other content-types to HTTP URLs."  I
> was assuming this was done precisely to avoid multiple items.

I think Example 10 is in conflict with that reading.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Holger Weiß]

* Kevin Smith  [2017-12-11 15:34]:
> 84 allows you to publish multiple versions of an avatar, each of which
> goes to its own item within the node, which would require multiple
> items.

It says the user "publishes avatar data for 'image/png' content-type to
data node and optionally publishes other content-types to HTTP URLs."  I
was assuming this was done precisely to avoid multiple items.

Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Kevin Smith]

On 7 Dec 2017, at 08:31, Jonas Wielicki  wrote:
 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 you’re right :)
84 allows you to publish multiple versions of an avatar, each of which goes to 
its own item within the node, which would require multiple items. At least, 
that’s my reading of it.

 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.

Yes.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Jonas Wielicki]

On Mittwoch, 6. Dezember 2017 18:58:32 CET Kevin Smith wrote:
> On 6 Dec 2017, at 18:47, Sam Whited  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
___

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

[Kevin Smith]

On 6 Dec 2017, at 18:47, Sam Whited  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-unsubscr...@xmpp.org
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Sam Whited]

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.

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.

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

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

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

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

> 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-unsubscr...@xmpp.org
___

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

[Kevin Smith]

On 1 Nov 2017, at 16:47, Jonas Wielicki  wrote:
> 
> On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote:
>> This message constitutes notice of a Last Call for comments on
>> XEP-0387.
>> 
>> Abstract:
>> This document defines XMPP protocol compliance levels for 2017.
>> 
>> This Last Call begins today and shall end at the close of business on
>> 2017-10-30.
> 
> The Last Call is extended until 2017-11-15 on behalf of the XMPP Council.

Some somewhat late feedback on this:

I think 49 needs to be in there for servers - it’s widely needed to make 
clients useful.
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).
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.
48 makes 223 support implicit, but I think making it explicit would be sensible.
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. Not a hill for me to die on again, but - should we ask for more? Like a 
pointer to which components work with that server to make them compliant? Maybe 
that we’re not doing testing makes it irrelevant anyway.
57 seems a fairly core requirement that’s missing, 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.
I think 220 should probably be in there, even today, but hills, dying, etc.

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.



/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Sam Whited]

I appreciate all of the discussion around the component protocol. I'm
still pretty torn on which direction is right, but for now I've decided
that this isn't important enough to block progress on. I am going to
leave it in and ask the council for a vote (I already did actually,
sorry, sent this email late).

As soon as it's accepted (if it's accepted) I will start the 2019 suites
for acceptance next year and we can reevaluate and continue this
discussion then.

Thanks all!

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Brian Cully]

On November 15, 2017 at 03:59:46, Ruslan N. Marchenko (m...@ruff.mobi) wrote:
>
>
> On 14.11.2017 22:37, Sam Whited wrote:
> >
> > What do the server devs here think?
> >
> >
> To be fair this protocol is implemented in majority(?) of existing xmpp
> server implementations so the burden is zero.
> The question is rather - what is the future vision for this component
> protocol? It considered as a necessary communication method for new
> external services or s2s with all the new features (like bidi) is
> sufficient making this one redundant. My personal answer is - go S2S.
> But at the same time i'm not doing much of component development
> therefore cannot say whether XEP-0114 is really resolving some corner
> cases hence being irreplaceable.

It’s not that 0114 isn’t irreplaceable, that I can see, it’s that
it’s dead simple to implement and debug. IMHO, it’s a fairly low
burden for server devs, and a positive boon for component devs, since
there’s just so much less that has to be worried about vs. s2s. In
addition, there are a fair number of extant components out there that
Just Work™.

-bjc
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Dave Cridland]

On 15 November 2017 at 08:59, Ruslan N. Marchenko  wrote:
>
>
> On 14.11.2017 22:37, Sam Whited wrote:
>>
>>
>> What do the server devs here think?
>>
>>
> To be fair this protocol is implemented in majority(?) of existing xmpp
> server implementations so the burden is zero.
> The question is rather - what is the future vision for this component
> protocol? It considered as a necessary communication method for new external
> services or s2s with all the new features (like bidi) is sufficient making
> this one redundant. My personal answer is - go S2S. But at the same time i'm
> not doing much of component development therefore cannot say whether
> XEP-0114 is really resolving some corner cases hence being irreplaceable.

Having written Metre, which implements *only* S2S and '114, I can tell
you it's not straightforward. I've just spent a couple of weeks on
Openfire's implementation to remove a bug there, too, and I've worked
on other implementations as well - bugs are tricky to find, the edge
cases are many, authentication is a tricksy nightmare. If I were
writing a standalone XMPP service now, I wouldn't want to write
(another) S2S implementation - I'd want to just connect using a
lightweight protocol and have the server to do heavy lifting.

I did propose, as part of this work, a component protocol based on
profiling S2S with mandatory Bidi in order to replace '114, but
Council rejected this:

https://xmpp.org/extensions/inbox/s2s-components.html

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Ruslan N. Marchenko]

On 14.11.2017 22:37, Sam Whited wrote:


What do the server devs here think?


To be fair this protocol is implemented in majority(?) of existing xmpp 
server implementations so the burden is zero.
The question is rather - what is the future vision for this component 
protocol? It considered as a necessary communication method for new 
external services or s2s with all the new features (like bidi) is 
sufficient making this one redundant. My personal answer is - go S2S. 
But at the same time i'm not doing much of component development 
therefore cannot say whether XEP-0114 is really resolving some corner 
cases hence being irreplaceable.


Regards,
Ruslan
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Sam Whited]

Someone just pointed out to me that the compliance suties were still
referencing RFC 6122. I have updated them to reference RFC 7622 and the
new version will be published soon.

—Sam

On Wed, Nov 1, 2017, at 10:47, Jonas Wielicki wrote:
> On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote:
> > This message constitutes notice of a Last Call for comments on
> > XEP-0387.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Kevin Smith]

> On 14 Nov 2017, at 21:37, Sam Whited  wrote:
> 
>> On Tue, Nov 14, 2017, at 12:06, Dave Cridland wrote:
>> So arguing over whether it's a Core, Advanced, or neither feature
>> seems a bit pointless - except that it means XEP-0387 may reflect
>> neither the current reality nor any particular desirable future.
> 
> I think the distinction between Core/Advanced might not be fantastic and
> have ideas for changing that, but I wasn't going to bring it up until we
> start on next years.
> 
> As it stands right now, I could still go either way on this and think
> the only thing that really matters is "does it present an undue burden
> for server developers to implement"? I'm not sure. It was a bit of a
> pain that last time I implemented it (and required a major refactoring
> of the way I handle connections), but I had assumed that was just my
> library because I hadn't considered alternative stream negotiation
> protocols at all (presumably if I'd done the websocket protocol first it
> would have been the same problem).
> 
> What do the server devs here think?

My knee-jerk reaction was that it should go. My slightly more considered 
reaction is that it should stay. It’s not particularly onerous to implement, 
and it’s widely used (and, importantly for Dave’s criterion, expected). 

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Sam Whited]

On Tue, Nov 14, 2017, at 12:06, Dave Cridland wrote:
> So arguing over whether it's a Core, Advanced, or neither feature
> seems a bit pointless - except that it means XEP-0387 may reflect
> neither the current reality nor any particular desirable future.

I think the distinction between Core/Advanced might not be fantastic and
have ideas for changing that, but I wasn't going to bring it up until we
start on next years.

As it stands right now, I could still go either way on this and think
the only thing that really matters is "does it present an undue burden
for server developers to implement"? I'm not sure. It was a bit of a
pain that last time I implemented it (and required a major refactoring
of the way I handle connections), but I had assumed that was just my
library because I hadn't considered alternative stream negotiation
protocols at all (presumably if I'd done the websocket protocol first it
would have been the same problem).

What do the server devs here think?

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Dave Cridland]

On 14 November 2017 at 18:48, Diane Trout  wrote:
> On Tue, 2017-11-14 at 18:06 +, Dave Cridland wrote:
>> But it's also a compromise without effect - every existing
>> implementation fo S2S I can find, excepting Microsoft Lync, supports
>> XEP-0114 "accept" components.
>>
>> So arguing over whether it's a Core, Advanced, or neither feature
>> seems a bit pointless - except that it means XEP-0387 may reflect
>> neither the current reality nor any particular desirable future.
>
> Alternatively can servers that don't support federation be considered
> compliant with XMPP in any meaningful sense?
>

Well... XMPP compliant, certainly. Useful for XEP-0387? Not so much.

> For instance the ojsxc[1] app in Nextcloud installs a minimal local
> only xmpp server that seems to only support the jabber:iq:roster,
> jabber:client, and vcard-temp namespaces.
>
> XEP 387 has specialized client compliance suites, you could also
> consider specifiying a server suite to specify what is needed to
> "support federation".

I don't think there's anything we'd put there except RFC 6120.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Diane Trout]

On Tue, 2017-11-14 at 18:06 +, Dave Cridland wrote:
> But it's also a compromise without effect - every existing
> implementation fo S2S I can find, excepting Microsoft Lync, supports
> XEP-0114 "accept" components.
> 
> So arguing over whether it's a Core, Advanced, or neither feature
> seems a bit pointless - except that it means XEP-0387 may reflect
> neither the current reality nor any particular desirable future.

Alternatively can servers that don't support federation be considered 
compliant with XMPP in any meaningful sense?

For instance the ojsxc[1] app in Nextcloud installs a minimal local
only xmpp server that seems to only support the jabber:iq:roster,
jabber:client, and vcard-temp namespaces.

XEP 387 has specialized client compliance suites, you could also
consider specifiying a server suite to specify what is needed to
"support federation".

Diane

[1] https://apps.nextcloud.com/apps/ojsxc
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Dave Cridland]

On 14 November 2017 at 17:57, Sam Whited  wrote:
> On Tue, Nov 14, 2017, at 11:18, Diane Trout wrote:
>> XEP-0114 could reasonably be considered an advanced feature, so maybe
>> it doesn't need to be a requirement for the "core server".
>
> That sounds reasonable to me and I'm inclined to go make the change.
> Dave, Arc?

I feel that's a compromise without virtue.

But it's also a compromise without effect - every existing
implementation fo S2S I can find, excepting Microsoft Lync, supports
XEP-0114 "accept" components.

So arguing over whether it's a Core, Advanced, or neither feature
seems a bit pointless - except that it means XEP-0387 may reflect
neither the current reality nor any particular desirable future.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Sam Whited]

On Tue, Nov 14, 2017, at 11:18, Diane Trout wrote:
> XEP-0114 could reasonably be considered an advanced feature, so maybe
> it doesn't need to be a requirement for the "core server".

That sounds reasonable to me and I'm inclined to go make the change.
Dave, Arc?

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Diane Trout]

> 
> I could go either way on this; if anything I'm leaning slightly
> towards
> removing it. However, so far everyone else seems to be in favor of
> keeping it, is there anyone else in support of removing it?
> 

XEP-0114 could reasonably be considered an advanced feature, so maybe
it doesn't need to be a requirement for the "core server".

Diane
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Dave Cridland]

On 13 November 2017 at 23:50, Sam Whited  wrote:
> On Mon, Nov 13, 2017, at 14:03, Arc Riley wrote:
>> The question is whether a server implementation should be considered
>> modern
>> and complete if it does not implement XEP-0114, and I've made what I
>> believe are strong arguments as to why XEP-0114 should not be considered
>> mandatory.
>
> I could go either way on this; if anything I'm leaning slightly towards
> removing it. However, so far everyone else seems to be in favor of
> keeping it, is there anyone else in support of removing it?

I commented in xsf@ a while back, but to reiterate, I lean toward
including it. I base my opinion on two assertions:

1) Every implementation of S2S (so every XMPP server plus Metre) also
implements XEP-0114.

Either it is utterly trivial to implement, or else it is desirable in
the marketplace. Much of XEP-0387's purpose is to give a reasonable
"shopping list" of what a new server developer should implement to be
competitive, so if it's a desirable feature we should just go with
that, and if it's trivial; to implement that there's no harm in doing
so.

One could argue, of course, that this is also evidence that if we do
not include XEP-0114 in XEP-0387, it doesn't matter, because people
"in the know" will implement it anyway. In which case, I'd be
concerned with the point of XEP-0387 at all.

2) Interoperability and Interfaces.

An XMPP Server has up to three interfaces to external systems.  C2S,
S2S, and Components. XEP-0387 does, of course, concentrate on C2S, but
I see no particular reason why it should not also include S2S features
and Component features. To a Client, or another Server, then
Components are indeed the internal implementation issue that Arc says
they are - but to the Server itself, or a Component of course, it's a
rather different matter. I don't see there's the fundamental argument
that Arc implies that Components are of lesser importance than other
interfaces.

To put things another way, it would be possible to implement an XMPP
Server that doesn't do S2S. After all, to a Client, all domains aside
from the home service look the same, right? Just an implementation
detail. Obviously this would be a bizarre argument to make, and nobody
is making it - it would be arguing that federation is an undesirable
feature. I think Components are, similarly, a desirable part of the
XMPP ecosystem, and we should support their existence.

As a final note, however, I would be emphatically opposed to including
any encouragement for "jabber:component:connect" - in fact, I think we
should get rid of that from XEP-0114 entirely.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Sam Whited]

On Mon, Nov 13, 2017, at 14:03, Arc Riley wrote:
> The question is whether a server implementation should be considered
> modern
> and complete if it does not implement XEP-0114, and I've made what I
> believe are strong arguments as to why XEP-0114 should not be considered
> mandatory.

I could go either way on this; if anything I'm leaning slightly towards
removing it. However, so far everyone else seems to be in favor of
keeping it, is there anyone else in support of removing it?

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Arc Riley]

On Thu, Nov 9, 2017 at 11:13 PM, Kim Alvefur  wrote:

>
> But perhaps this one?
> https://xmpp.org/extensions/xep-0355.html
>

XEP-0355 is not included in the last call 2018 compliance suite. The issue
I raised was over XEP-0114.

The question is whether a server implementation should be considered modern
and complete if it does not implement XEP-0114, and I've made what I
believe are strong arguments as to why XEP-0114 should not be considered
mandatory.

There are plenty of "cool" and "useful" XEPs that don't appear on this
list, for example XEP-0363 (HTTP Upload).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Kim Alvefur]

On Thu, Nov 09, 2017 at 10:26:37PM -0800, Arc Riley wrote:
> However, XEP-0114 does not cover the ability to have an external
> process add support for a new XEP. [...], but AFAIK that protocol
> has never been documented in a XEP - certainly not this one.

But perhaps this one?
https://xmpp.org/extensions/xep-0355.html


-- 
Zash


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Arc Riley]

On Thu, Nov 9, 2017 at 5:00 PM, Diane Trout  wrote:

> Also a better justification for the component protocol is that it
> allows people to develop reasonably portable new features like xep 363.
> https://github.com/siacs/HttpUploadComponent


I agree with you that being able to implement a new feature with a
server-agnostic codebase is a cool feature.

However, XEP-0114 does not cover the ability to have an external process
add support for a new XEP. That is certainly a feature that many modern
XMPP servers support, but AFAIK that protocol has never been documented in
a XEP - certainly not this one.

Further, there's absolutely valid reasons why an author may not want to
support it (eg, security).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Diane Trout]

> I'd rather focus on getting a successor, possibly xep0255, out of the
> door. And if we see that major components (spectrum2 comes to my
> mind)
> and servers support the successor, we could consider removing xep0114
> from the compliance suite. But not before that has happened.

This seems like a reasonable position, other than I think it's XEP-
0225.

For what its worth I was trying to write a gateway using the component
protocol.

Also a better justification for the component protocol is that it 
allows people to develop reasonably portable new features like xep 363.
https://github.com/siacs/HttpUploadComponent

Diane

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
___

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

[Ruslan N. Marchenko]

On 09.11.2017 23:54, Arc Riley wrote:
On Thu, Nov 9, 2017 at 12:30 PM, Florian Schmaus > wrote:


Fact is, if you would implement a new XMPP server without xep114,
you would
miss a lot of fun.


I haven't run an XMPP component since the early 2000's and I did not 
find it "fun". Quite the opposite actually, but this is beside the point.


I second that, have C2S driver disabled for ages, never came to a 
thought to enable it.


--RR
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Arc Riley]

On Thu, Nov 9, 2017 at 12:30 PM, Florian Schmaus  wrote:

> A component protocols allows components to piggyback on the
> s2s capabilities of the XMPP server. And s2s is not trivial to implement
> (Dialback, SASL EXTERNAL, possibly BIDI, …). Therefore a component
> protocol allows developers to focus on the implementation of the
> component's actual task.
>

This is still an implementation detail. It has zero nominal impact on XMPP
clients or other servers. I would like to see the compliance suite agnostic
to implementation details.

I do not believe S2S is more complicated than implementing component
protocol. For legacy services implemented using component protocol, an XMPP
reverse proxy could be implemented separately from a service provider's
"main" XMPP server and (besides running on a different port) it would be
indistinguishable from running it internal to that "main" server.



Fact is, if you would implement a new XMPP server without xep114, you would
> miss a lot of fun.
>

I haven't run an XMPP component since the early 2000's and I did not find
it "fun". Quite the opposite actually, but this is beside the point.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Florian Schmaus]

On 09.11.2017 20:10, Arc Riley wrote:
> Correct me if I'm wrong, but I remember the primary purpose of component
> protocol was to multihome gateways and other services (eg, MUC) on a
> single XMPP server which bound to the S2S port. Without this, you'd
> either need an XMPP reverse proxy (which component protocol almost is,
> almost) or one IP address per service you wanted to host.
> 
> SRV records allow each service to be bound to a different port,
> eliminating the need for a single server to proxy S2S connections to
> respective services. This implementation detail should have zero nominal
> impact on either clients or S2S, lack of it as a feature would only
> impact sysadmins trying to run XMPP components.

Ahh, now I understand what you mean.

But I feels like you are arguing that because we have SRV records, a
component protocol is no longer required. I wouldn't come to that
conclusion. A component protocols allows components to piggyback on the
s2s capabilities of the XMPP server. And s2s is not trivial to implement
(Dialback, SASL EXTERNAL, possibly BIDI, …). Therefore a component
protocol allows developers to focus on the implementation of the
component's actual task.

> Beyond that, I'd think any XEP on the MTI list should be standards
> track, not historical. 

I don't care which track it is on in this case. It just formalism. Fact
is, if you would implement a new XMPP server without xep114, you would
miss a lot of fun.

I'd rather focus on getting a successor, possibly xep0255, out of the
door. And if we see that major components (spectrum2 comes to my mind)
and servers support the successor, we could consider removing xep0114
from the compliance suite. But not before that has happened.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Arc Riley]

Correct me if I'm wrong, but I remember the primary purpose of component
protocol was to multihome gateways and other services (eg, MUC) on a single
XMPP server which bound to the S2S port. Without this, you'd either need an
XMPP reverse proxy (which component protocol almost is, almost) or one IP
address per service you wanted to host.

SRV records allow each service to be bound to a different port, eliminating
the need for a single server to proxy S2S connections to respective
services. This implementation detail should have zero nominal impact on
either clients or S2S, lack of it as a feature would only impact sysadmins
trying to run XMPP components.

Beyond that, I'd think any XEP on the MTI list should be standards track,
not historical.


On Wed, Nov 8, 2017 at 11:57 PM, Florian Schmaus  wrote:

> On 09.11.2017 02:07, Arc Riley wrote:
> > Since XEP-0114 is historical and its purpose predates SRV records, I'm
> > wondering why it was included in the suite for server compliance?
>
> Because it is still the de-facto standard how you plug in external
> components into your XMPP server. :)
>
> And what do you mean with "purpose predates SRV records"?
>
> XEP-0114 components can be used with SRV records. If you want the
> component to be accessible by other XMPP servers, you just point the
> components _xmpp-server SRV record to the s2s port of your XMPP server.
> At least that is how I remember it to work.
>
> I'm not sure what a new XMPP component protocol should do
> different/better wrt. SRV records?
>
> - Florian
>
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Florian Schmaus]

On 09.11.2017 02:07, Arc Riley wrote:
> Since XEP-0114 is historical and its purpose predates SRV records, I'm
> wondering why it was included in the suite for server compliance?

Because it is still the de-facto standard how you plug in external
components into your XMPP server. :)

And what do you mean with "purpose predates SRV records"?

XEP-0114 components can be used with SRV records. If you want the
component to be accessible by other XMPP servers, you just point the
components _xmpp-server SRV record to the s2s port of your XMPP server.
At least that is how I remember it to work.

I'm not sure what a new XMPP component protocol should do
different/better wrt. SRV records?

- Florian




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Sam Whited]

On Wed, Nov 8, 2017, at 19:07, Arc Riley wrote:
> Since XEP-0114 is historical and its purpose predates SRV records, I'm
> wondering why it was included in the suite for server compliance?

As far as I can tell it is still widely used for transports, plugins,
etc. so it seemed worth including. I'm not against removing it through
if it presents an undue burden to implement.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Arc Riley]

Since XEP-0114 is historical and its purpose predates SRV records, I'm
wondering why it was included in the suite for server compliance?



On Tue, Nov 7, 2017 at 11:41 AM, Sam Whited  wrote:

>
>
> On Wed, Nov 1, 2017, at 11:50, Dave Cridland wrote:
> > On 1 November 2017 at 17:14, Sam Whited  wrote:
> > > On Wed, Nov 1, 2017, at 11:47, Jonas Wielicki wrote:
> > >> On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote:
> > >> > This message constitutes notice of a Last Call for comments on
> > >> > XEP-0387.
> > >
> > > What would folks think about changing the title of these compliance
> > > suites to "2018" and then moving them forward by the end of the year?
> > >
> > > Then we can start working on the 2019 suites throughout next year and
> > > start trying to have the years compliance suites in by January 1st of
> > > the year in the title.
> > >
> >
> > Let's do this.
>
> I have bumped the year now; it will be published later. Since this was
> the only change, consider this the alert for a new version of the suites
> which we can vote on when the LC expires.
>
> Thanks!
>
> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Sam Whited]

On Wed, Nov 1, 2017, at 11:50, Dave Cridland wrote:
> On 1 November 2017 at 17:14, Sam Whited  wrote:
> > On Wed, Nov 1, 2017, at 11:47, Jonas Wielicki wrote:
> >> On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote:
> >> > This message constitutes notice of a Last Call for comments on
> >> > XEP-0387.
> >
> > What would folks think about changing the title of these compliance
> > suites to "2018" and then moving them forward by the end of the year?
> >
> > Then we can start working on the 2019 suites throughout next year and
> > start trying to have the years compliance suites in by January 1st of
> > the year in the title.
> >
> 
> Let's do this.

I have bumped the year now; it will be published later. Since this was
the only change, consider this the alert for a new version of the suites
which we can vote on when the LC expires.

Thanks!

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Dave Cridland]

On 1 November 2017 at 17:14, Sam Whited  wrote:
> On Wed, Nov 1, 2017, at 11:47, Jonas Wielicki wrote:
>> On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote:
>> > This message constitutes notice of a Last Call for comments on
>> > XEP-0387.
>
> What would folks think about changing the title of these compliance
> suites to "2018" and then moving them forward by the end of the year?
>
> Then we can start working on the 2019 suites throughout next year and
> start trying to have the years compliance suites in by January 1st of
> the year in the title.
>

Let's do this.

> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Peter Saint-Andre]

On 11/1/17 11:14 AM, Sam Whited wrote:
> On Wed, Nov 1, 2017, at 11:47, Jonas Wielicki wrote:
>> On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote:
>>> This message constitutes notice of a Last Call for comments on
>>> XEP-0387.
> 
> What would folks think about changing the title of these compliance
> suites to "2018" and then moving them forward by the end of the year?
> 
> Then we can start working on the 2019 suites throughout next year and
> start trying to have the years compliance suites in by January 1st of
> the year in the title.

+1




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Sam Whited]

On Wed, Nov 1, 2017, at 11:47, Jonas Wielicki wrote:
> On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote:
> > This message constitutes notice of a Last Call for comments on
> > XEP-0387.

What would folks think about changing the title of these compliance
suites to "2018" and then moving them forward by the end of the year?

Then we can start working on the 2019 suites throughout next year and
start trying to have the years compliance suites in by January 1st of
the year in the title.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Jonas Wielicki]

On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0387.
> 
> Abstract:
> This document defines XMPP protocol compliance levels for 2017.
> 
> This Last Call begins today and shall end at the close of business on
> 2017-10-30.

The Last Call is extended until 2017-11-15 on behalf of the XMPP Council.

kind regards,
Jonas Wielicki (with my Editor hat on)

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
___