Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)
(And this time I’ll remember to thank Georg for taking this on. Thanks Georg) > On 6 Nov 2019, at 13:43, Georg Lukas wrote: > > * Kevin Smith [2019-11-06 12:24]: >> I think the addition of ’66 is well-intentioned, but jabber:x:oob >> is underspecified (it defines a syntax, but semantics are >> missing). > > I agree, but nobody has written down the semantics yet, so there is no > place to link to. On the other hand, this approach seems to be so widely > used (despite me hating it), that it would be bad _not_ to tell > developers about it at all. I think it would be fine to drop a note in saying that ’66 isn’t required by the suite, but that it is sometimes used and worth looking at, or something. >> I think 286 (LTE mobile) is worth a mention, but how would one be >> compliant with it as a client or server? > > By having the author read 286 ;-) I think a note to that effect is worthwhile. >> I note that while requiring TLS is right, I suspect very few, if any, >> implementations follow 7590 (and by extension 7525). It’s also >> inconsistent to require 7590 (and 7525) in core, but direct TLS (which >> 7525 would need) only in advanced. > > I read your remark as "7525 makes Direct TLS mandatory", which I can not > see in the RFC. 7525 says that deployments SHOULD prefer "strict TLS" > (which is not really defined) over "dynamic upgrade" if supported. Strict may not be explicitly defined, but the dynamic that you need to prefer it over is defined to include STARTTLS. So I do read it as saying that you need to prefer direct TLS to STARTTLS where a protocol allows it (which we do these days). This was, though, just a note and I’m not pushing for a text change. >> My only note on this is that I think the introduction to “Future >> Development” isn’t right - these are protocols that aren’t ready to be >> required by the compliance suite, rather than not ready for production >> use. > > I've updated the text accordingly; a rendered version of your and other > LC responses can be found at https://op-co.de/tmp/xep-0423.html Thanks. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)
On 6 Nov 2019, at 13:57, Daniel Gultsch wrote: > > Am Mi., 6. Nov. 2019 um 13:45 Uhr schrieb Georg Lukas : >> >> * Kevin Smith [2019-11-06 12:24]: >>> I think the addition of ’66 is well-intentioned, but jabber:x:oob >>> is underspecified (it defines a syntax, but semantics are >>> missing). >> >> I agree, but nobody has written down the semantics yet, so there is no >> place to link to. On the other hand, this approach seems to be so widely >> used (despite me hating it), that it would be bad _not_ to tell >> developers about it at all. > > I think there is a broader discussion buried in there and that is do > we want the Compliance Suite to be a guide for developers of the > publicly federating XMPP network or for independent developers who > just want to build their own solution based on XMPP. > The former may find information regarding the current-but arguably not > very ideal-solution useful. The later will find that utterly confusing > and would prefer a 'clean' solution. At the risk of derailing the conversation, I think there are more nuanced options than these. Some considerations only apply to the Internet. Some others apply whenever you want interop with off the shelf software, which might be on (for want of a better description) a ‘private Internet’ - e.g. those things you need to support because that’s what the state of the art is you will very possibly still need to support in such cases, even though it’s not on the Internet Proper. Yes, there are also the ‘completely closed’ cases where you only use XMPP for the re-use of existing things, rather than for the interop, and these have different considerations. > Not that 0066 is just one example were this problem manifests itself. I think 66 has problems beyond just this, though, as the appropriate way to use it just isn’t documented that I can see. I don’t think it can be in a compliance suite as-is. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)
Am Mi., 6. Nov. 2019 um 13:45 Uhr schrieb Georg Lukas : > > * Kevin Smith [2019-11-06 12:24]: > > I think the addition of ’66 is well-intentioned, but jabber:x:oob > > is underspecified (it defines a syntax, but semantics are > > missing). > > I agree, but nobody has written down the semantics yet, so there is no > place to link to. On the other hand, this approach seems to be so widely > used (despite me hating it), that it would be bad _not_ to tell > developers about it at all. I think there is a broader discussion buried in there and that is do we want the Compliance Suite to be a guide for developers of the publicly federating XMPP network or for independent developers who just want to build their own solution based on XMPP. The former may find information regarding the current-but arguably not very ideal-solution useful. The later will find that utterly confusing and would prefer a 'clean' solution. Not that 0066 is just one example were this problem manifests itself. Previous iterations of the Compliance Suite had less friction points with those two potentially different audiences. My general thought is to - until we are clear on who the audience of the compliance suite is - not include information that can be confusing to either one. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)
* Kevin Smith [2019-11-06 12:24]: > I think the addition of ’66 is well-intentioned, but jabber:x:oob > is underspecified (it defines a syntax, but semantics are > missing). I agree, but nobody has written down the semantics yet, so there is no place to link to. On the other hand, this approach seems to be so widely used (despite me hating it), that it would be bad _not_ to tell developers about it at all. > I think 392 (consistent colours) is worth a mention, but not as a requirement > at this stage. Noted. There wass significant backlash against the addition of it, and I'd like to have a brief discussion of it in today's Council. By now I almost expect it to be moved into "Future" afterwards. > I would rather see bookmarks2 as a requirement than 411, but don’t > hugely care. Good point. Bookmarks2 makes legacy-compat optional, but I would like to mandate legacy support in the CS. Also I would like to see an explicit statement that bookmarks added via Bookmarks2 become visible to Private-XML and Legacy-PEP clients. Also given that Bookmarks2 isn't widely supported yet, I have a better feeling with it being in "Future". > What does a client need to do to implement 411 though? Nothing. I just was too lazy to split out the conversion into its own dedicated table row. > I think 286 (LTE mobile) is worth a mention, but how would one be > compliant with it as a client or server? By having the author read 286 ;-) > I note that while requiring TLS is right, I suspect very few, if any, > implementations follow 7590 (and by extension 7525). It’s also > inconsistent to require 7590 (and 7525) in core, but direct TLS (which > 7525 would need) only in advanced. I read your remark as "7525 makes Direct TLS mandatory", which I can not see in the RFC. 7525 says that deployments SHOULD prefer "strict TLS" (which is not really defined) over "dynamic upgrade" if supported. Even when implying "Strict TLS" = "Direct TLS", we do not mandate support for Direct TLS, so I don't see a violation here. > My only note on this is that I think the introduction to “Future > Development” isn’t right - these are protocols that aren’t ready to be > required by the compliance suite, rather than not ready for production > use. I've updated the text accordingly; a rendered version of your and other LC responses can be found at https://op-co.de/tmp/xep-0423.html A PR will be generated shortly. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || ++ IRCnet OFTC OPN ||_|| 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-0423 (XMPP Compliance Suites 2020)
> On 23 Oct 2019, at 16:07, Jonas Schäfer (XSF Editor) > wrote: > > This message constitutes notice of a Last Call for comments on > XEP-0423. > > Title: XMPP Compliance Suites 2020 > Abstract: > This document defines XMPP application categories for different use > cases (Core, Web, IM, and Mobile), and specifies the required XEPs > that client and server software needs to implement for compliance with > the use cases. > > URL: https://xmpp.org/extensions/xep-0423.html > > This Last Call begins today and shall end at the close of business on > 2019-11-06. > > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? I don’t think the Compliance Suites are the right thing to be doing, but at the moment we don’t have anything better to address the ‘provide guidance to implementors’ need. > 2. Does the specification solve the problem stated in the introduction > and requirements? I think the addition of ’66 is well-intentioned, but jabber:x:oob is underspecified (it defines a syntax, but semantics are missing). I think 392 (consistent colours) is worth a mention, but not as a requirement at this stage. I would rather see bookmarks2 as a requirement than 411, but don’t hugely care. What does a client need to do to implement 411 though? I think 286 (LTE mobile) is worth a mention, but how would one be compliant with it as a client or server? I note that while requiring TLS is right, I suspect very few, if any, implementations follow 7590 (and by extension 7525). It’s also inconsistent to require 7590 (and 7525) in core, but direct TLS (which 7525 would need) only in advanced. > 3. Do you plan to implement this specification in your code? If not, > why not? Not in the short term - I think the document is more useful as guidance than it is as a hard compliance test. > > 4. Do you have any security concerns related to this specification? I think ’66’s security considerations are likely not adequate for the current Internet (particularly around privacy). > 5. Is the specification accurate and clearly written? Mostly. The ‘Changes since 2019’ section is very useful. My only note on this is that I think the introduction to “Future Development” isn’t right - these are protocols that aren’t ready to be required by the compliance suite, rather than not ready for production use. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)
Hi goffi, * goffi [2019-11-05 22:58]: > I'm really busy these days and couldn't do an extensive review, but here is > my feedback: Thank you for your feedback! > It's really chat focused, and I would like to see other categories, notably > a "social" one. I would put there XEP-0277 as the bare minimum, and RSM for > PubSub + MAM for Pubsub for advanced clients. Unfortunately, I'm veery time-bound this week, but I need to bring the Draft proposal up in today's Council. I would very kindly ask you, and everybody else involved in Social IM, to provide a PR, or a free-form table that corresponds to our typical Core/Advanced distinction with different labeled entries, in the next days / weeks. We can then add it into the Draft XEP under the new Council. > Why Jingle SOCKS5 Bytestreams Transport Method (XEP-0260) is missing from > the list while XEP-0261 is there? XEP-0234 requires support for 0261 at a minimum, and mentions 0260 as recommended, so it should be discoverable by prospective developers. The Compliance Suite doesn't have a notion for "recommended", so everything listed there must be implemented, on the other hand. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || ++ IRCnet OFTC OPN ||_|| 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-0423 (XMPP Compliance Suites 2020)
Oops, sorry, wrong thread. I was mentioning XEP-0402 (Bookmarks 2) of course. On Wed, Nov 6, 2019 at 8:53 AM, Evgeny wrote: ... ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)
On Wed, Oct 23, 2019 at 9:41 PM, Paul Schaub wrote: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? The purpose of the XEP is unclear. The only mentioned "advantage" is that it allows to publish multiple "items". And? 3. Do you plan to implement this specification in your code? If not, why not? No. Because I see no reason to introduce 3rd version of bookmarks and breaking compatibility without clear benefits. 4. Do you have any security concerns related to this specification? No. 5. Is the specification accurate and clearly written? Seems so. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)
Hello, I'm really busy these days and couldn't do an extensive review, but here is my feedback: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Definitely, there is a high demand for this kind of list from users, and on the dev side it's really useful for newcomers to have a starting point and to know where to look at. 2. Does the specification solve the problem stated in the introduction and requirements? It's really chat focused, and I would like to see other categories, notably a "social" one. I would put there XEP-0277 as the bare minimum, and RSM for PubSub + MAM for Pubsub for advanced clients. Also I have the feeling that the XEP numbers support is not enough, as a XEP can be only partially supported (for instance, support for XEP-0060 is really different from one software to an other), so a more fine-grained indicator could be useful. On the other hand, it may over-complicate the compliance suit, so I'm just throwing the idea. I wonder also if it would make sense to announce a compliance support in disco, so a client could check a server compliance without having to check all XEPs namespaces individually. Why Jingle SOCKS5 Bytestreams Transport Method (XEP-0260) is missing from the list while XEP-0261 is there? 3. Do you plan to implement this specification in your code? If not, why not? For this specific XEP there is no notion of implementation, but I'm using it to have an idea of what I need to implement yes. 4. Do you have any security concerns related to this specification? no 5. Is the specification accurate and clearly written? the specification is clear. off-topic: As a side note, it would be useful to have the notes showed in hover tooltips in the rendered XEP, that would avoid to go down and up just to read them. I hope this will be useful Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)
Hi! I'm not quite happy with the fact that an advanced mobile client must support push. While I understand the rationale behind this (*cough* iOS *cough*), I dislike the fact that in order to be considered an advanced client, the client MUST depend on a centralized push service (for example Google GCM/Firebase/whatever it is called nowadays). I can only speak for my own experiences, but I never had issues with battery life without Google services. Paul Wed Oct 23 17:07:41 GMT+02:00 2019 Jonas Schäfer (XSF Editor) : > This message constitutes notice of a Last Call for comments on > XEP-0423. > > Title: XMPP Compliance Suites 2020 > Abstract: > This document defines XMPP application categories for different use > cases (Core, Web, IM, and Mobile), and specifies the required XEPs > that client and server software needs to implement for compliance with > the use cases. > > URL: https://xmpp.org/extensions/xep-0423.html > > This Last Call begins today and shall end at the close of business on > 2019-11-06. > > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? > > 2. Does the specification solve the problem stated in the introduction > and requirements? > > 3. Do you plan to implement this specification in your code? If not, > why not? > > 4. Do you have any security concerns related to this specification? > > 5. Is the specification accurate and clearly written? > > Your feedback is appreciated! > ___ > 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-0423 (XMPP Compliance Suites 2020)
Thanks for the effort to push this well before the end of the year. :) On my first reading, I noticed two things: XEP-0385 "Stateless Inline Media Sharing (SIMS)" is mentioned both in section 1.1 "Changes since 2019", but also in section 3 "Future Development". Is that an error, or intended? I'd argue that if you're including something in this edition of the CS, then there's no point of adding it also as a 'keep an eye on this one for the future' I am surprised to see XEP-0392 "Consistent Color Generation" in the CS. What's the rationale to include it? Without giving this to much thought, I've regarded this XEP more as a useful guide for those who'd explicitly choose to implement a, rather than something that is required to implement to be considered 'compliant'. I'm expecting that there are projects that explicitly not want this (in favor of marketing-driven decisions on look-and-feel, themes, colors, etc). Is the functionality described this XEP of such a nature that we'd be willing to mandate it? Regards, Guus On Wed, 23 Oct 2019 at 17:07, Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on > XEP-0423. > > Title: XMPP Compliance Suites 2020 > Abstract: > This document defines XMPP application categories for different use > cases (Core, Web, IM, and Mobile), and specifies the required XEPs > that client and server software needs to implement for compliance with > the use cases. > > URL: https://xmpp.org/extensions/xep-0423.html > > This Last Call begins today and shall end at the close of business on > 2019-11-06. > > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? > > 2. Does the specification solve the problem stated in the introduction > and requirements? > > 3. Do you plan to implement this specification in your code? If not, > why not? > > 4. Do you have any security concerns related to this specification? > > 5. Is the specification accurate and clearly written? > > Your feedback is appreciated! > ___ > 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] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)
This message constitutes notice of a Last Call for comments on XEP-0423. Title: XMPP Compliance Suites 2020 Abstract: This document defines XMPP application categories for different use cases (Core, Web, IM, and Mobile), and specifies the required XEPs that client and server software needs to implement for compliance with the use cases. URL: https://xmpp.org/extensions/xep-0423.html This Last Call begins today and shall end at the close of business on 2019-11-06. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
