Re: [Standards] A Meta-Discussion about the Standards Process

[Dave Cridland]

On Sat, 18 Jan 2020 at 12:44, Marvin W  wrote:

> On 1/17/20 10:53 PM, Dave Cridland wrote:
> > In my experience, a lot of the draw for XMPP is the fact
> > it's an off-the-shelf solution with interoperable pieces. That's (at
> > least) a by-product of standardization.
>
> I see your point but I fail to see how it counters my point.


You seem to have failed to consider that it is possible that I was not
intending to counter your point but develop it further. :-)


> If they
> only care about the interoperable pieces, a WHATWG defining them for the
> most popular software is completely fine for them. They don't need a
> proper standard, they just need the off-the-shelf solution. You are
> exactly confirming that point with Pando by using off-the-shelf
> non-standard solutions by ESL. The important part for such uses is that
> this solution is cheaper than others, the standardization (= our unpaid
> work) is just what caused most of it.
>
>
I think your last point explains why my point is valid; indeed it echoes
the last statement of mine. Standardization is a method for commoditizing
useful software components, and it's a very useful and powerful method.
This means there are multiple suppliers available which drives down cost -
some of our suppliers have been open source, and some of them free. And for
what it's worth, Pando is interested in moving much more of its internals
to a standards basis precisely because of the advantages that successful
standardization provides - it amortizes the development costs across the
entire market.

But please do not keep dwelling on "unpaid". This seems to be a repeated
theme for you, and I'm somewhat concerned by the implications people may
read into this. We are, I think, all volunteers in our work with the XSF,
though I hope that as many of us as possible can generate some indirect
income out of that work. Increasing the applicability of our work increases
the potential market, and that in turn makes more income available for us -
I certainly wouldn't have landed the same jobs without there being a market
for my rather niche skills. And throughout my career, even when I have had
an agreement from my employer to work on XSF things in work time, I have
maintained an agreement that I participate as myself, and not the company.
But really, if you're doing this just for the money you're in entirely the
wrong space. I can suggest stock trading - and your XMPP skills will be
useful there too. ;-)

As for a WHATWG market-share driven plutocracy, that has problems for all
consumers of the standard. WHATWG does not output useful specifications for
others to implement and adopt, it outputs a common platform that consumers
of the standard must use and conform to. The difference is subtle, and
indeed it would be highly desirable to have that common platform as well.
But that common platform, being geared to one market to the exclusion of
others, would reduce a lot of the input we get into the community.


> > And, you know, being able to say "Military Grade Security" to the
> > enterprise market and actually *mean* it wouldn't be all bad.
> >
> > Losing Fortnite wouldn't, I admit, make a huge difference to most of the
> > community, though by the sounds of things, Guus would lose the respect
> > of his kid - and I can tell you that it gets a lot of interest when
> > you're trying to explain why XMPP is interesting to the crowd at FOSDEM.
>
> I see how it can help with marketing that known popular proprietary
> services use XMPP. On the other end, XSF (and the XMPP community) is so
> bad at marketing that I doubt it made a huge difference.
>
>
Being bad at marketing our efforts does not mean we should strive to be
worse, of course, but I readily agree we should be better at this.


> > I'm not sure that's true either - E2EE is really important to many
> > places, even walled gardens, and because the attraction of XMPP is a
> > proven technology that people can pick up and use, the fact that they
> > cannot with OMEMO is a serious problem. (Worse, OMEMO has been in use by
> > people presumably unaware that their software is inadvertently GPL).
>
> You are touching an interesting point here and while I don't want to
> open the OMEMO can again, I think it's worth mentioning how those two
> things you just said combine: If closed ecosystem companies primarily
> take off-the-shelf things they don't really care if the standard relies
> on a library that is under GPL, they care if there are off-the-shelf
> non-GPL implementations. So even if it turned out that OMEMO has no GPL
> issues, this wouldn't resolve their issue.


If a specification is able to be implemented by anyone without constraint
on their business model, and yet it still hasn't been, it's a failed
standard - de jure yet not de facto.

Failed standards do not carry the same benefit, this is absolutely true.

Dave.
___
Standards mailing list
Info: 

Re: [Standards] A Meta-Discussion about the Standards Process

[Marvin W]

On 1/17/20 10:53 PM, Dave Cridland wrote:
> In my experience, a lot of the draw for XMPP is the fact
> it's an off-the-shelf solution with interoperable pieces. That's (at
> least) a by-product of standardization.

I see your point but I fail to see how it counters my point. If they
only care about the interoperable pieces, a WHATWG defining them for the
most popular software is completely fine for them. They don't need a
proper standard, they just need the off-the-shelf solution. You are
exactly confirming that point with Pando by using off-the-shelf
non-standard solutions by ESL. The important part for such uses is that
this solution is cheaper than others, the standardization (= our unpaid
work) is just what caused most of it.

> And, you know, being able to say "Military Grade Security" to the
> enterprise market and actually *mean* it wouldn't be all bad.
> 
> Losing Fortnite wouldn't, I admit, make a huge difference to most of the
> community, though by the sounds of things, Guus would lose the respect
> of his kid - and I can tell you that it gets a lot of interest when
> you're trying to explain why XMPP is interesting to the crowd at FOSDEM.

I see how it can help with marketing that known popular proprietary
services use XMPP. On the other end, XSF (and the XMPP community) is so
bad at marketing that I doubt it made a huge difference.

> I'm not sure that's true either - E2EE is really important to many
> places, even walled gardens, and because the attraction of XMPP is a
> proven technology that people can pick up and use, the fact that they
> cannot with OMEMO is a serious problem. (Worse, OMEMO has been in use by
> people presumably unaware that their software is inadvertently GPL).

You are touching an interesting point here and while I don't want to
open the OMEMO can again, I think it's worth mentioning how those two
things you just said combine: If closed ecosystem companies primarily
take off-the-shelf things they don't really care if the standard relies
on a library that is under GPL, they care if there are off-the-shelf
non-GPL implementations. So even if it turned out that OMEMO has no GPL
issues, this wouldn't resolve their issue.

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Dave Cridland]

On Fri, 17 Jan 2020 at 19:28, Marvin W  wrote:

> On 1/17/20 11:38 AM, Dave Cridland wrote:
> > Well, yes, but the majority of our end-users are probably Fortnite
> > players, and they're not talking to us.
> I should have been more precise: I was talking about the open XMPP
> ecosystem, not any closed/walled garden XMPP implementations with own
> client/server and without federation. Those don't care too much about
> the standard anyway (they can just do proprietary vendor extensions and
> probably do).
>
>
That depends. In my experience, a lot of the draw for XMPP is the fact it's
an off-the-shelf solution with interoperable pieces. That's (at least) a
by-product of standardization.

So, for example, Pando (my employer) uses a lot of standards-based things,
and things which aren't standards but are still off the shelf (like ESL's
MUC Light and Inbox). There is some proprietary stuff, but there's also a
lot of "throw this thing in a message", which is not so useful (hence UDT).
Everything we do, though, is moving toward the standards - where we haven'
is mostly expediency. And Pando is (currently) a custom client talking to a
single XMPP service; in the terms you've described, it's a closed walled
garden. (I'll talk about, and show, our app at the Summit for those
interested; it's used across the National Health Service in the UK by
Doctors, Nurses etc as a primary communications tool).

But there are also lots of closed networks where the ability to use an
off-the-shelf client and server is very useful, and plenty more where at
least using a fully standardized server is useful. Fortnite is the latter,
and while I'm struggling to think of a good example of the former, they do
exist.

And then there's the militaries, where despite a closed network, there's a
lot of federation, and standards are fully mandated. Some players in that
market handle this by simply adopting standards, others handle that
constraint by very active involvement in the XSF and produce a number of
XEPs - and many of those are of use for a wider audience.


> The reason why WHATWG worked is that their specs were implemented by the
> majority of browsers (counted in users) and thus websites can and will
> rely on these specs. As soon as they do, any other browser will need to
> implement the same spec to stay compatible or loose even further market
> share. "Fortnite" wouldn't matter because they have a browser that can
> only display a single website and that website is only ever displayed in
> their browser.
>
>
Yes; the effect has also been to gradually reduce diversity in
the browsers, and lock out new entrants. But I think we're already agreed
that WHATWG, for all its successes, has had some serious downsides.

In the chatroom, after Guus commented on the one-liner you've replied to, I
said:

‎[10:48:05] ‎dwd‎: I probably should have expanded on that. But
"consumer-grade" instant messaging is pretty small beans for XMPP. Embedded
use of XMPP into games is, I think, the largest use by numbers of users,
and I'm not sure what would be next - probably military, though possibly
financial trading.
‎[10:49:28] ‎dwd‎: That doesn't mean I don't think consumer-grade messaging
isn't important, or that we should ignore enterprise messaging (ie, Slack)
because we're barely present. Strategically, both those make more sense to
concentrate on than gaming (and won't harm gaming either), at least in
terms of features.

I'll expand on this yet further:

The specifications we produce have to have relevance and adoption, that's
certainly true, and the consumer-grade messaging that the majority of the
Open Source folks are dealing with day-to-day is a very useful guide to
this. The military, being people, too, will end up using emoji-based
reactions - in fact, they'll probably mandate their use eventually. So
while the "personal IM" market is small for XMPP, it's probably leading in
terms of UX, it's highly accessible for us, and it's a good guide to what's
needed for current trends in messaging.

Similarly, though we have even less footprint in the enterprise case,
ignoring that would be extremely foolish for us - especially when the
incumbents have some increasingly difficult to solve UX issues, and are
edging toward some form of pseudo-federation that we can already give. We
should, from a strategic point of view, be focusing on the well-defined
needs of these two markets.

What I wouldn't want to do is focus on these or any particular markets
exclusively to the detriment of some of our other, often more outré and
esoteric, markets, which don't seem as exciting (or as pure, or whatever).
I appreciate that many have mixed feelings about the military use, for
example, but I would hope even committed pacifists in the community can at
least take some pride that XMPP dominates the military because of its
technical qualities (and the fact it's a recognised Open Standard). The
benefit to the community is that we have a more broadly applicable set of

Re: [Standards] A Meta-Discussion about the Standards Process

[Marvin W]

On 1/17/20 11:38 AM, Dave Cridland wrote:
> Well, yes, but the majority of our end-users are probably Fortnite
> players, and they're not talking to us.
I should have been more precise: I was talking about the open XMPP
ecosystem, not any closed/walled garden XMPP implementations with own
client/server and without federation. Those don't care too much about
the standard anyway (they can just do proprietary vendor extensions and
probably do).

The reason why WHATWG worked is that their specs were implemented by the
majority of browsers (counted in users) and thus websites can and will
rely on these specs. As soon as they do, any other browser will need to
implement the same spec to stay compatible or loose even further market
share. "Fortnite" wouldn't matter because they have a browser that can
only display a single website and that website is only ever displayed in
their browser.

OMEMO is kind of an example where we got in a similar situation: so many
clients (counted in user numbers) in the open XMPP ecosystem do support
it, that to stay compatible with the ecosystem, you kind of have to
implement it. That's mostly not relevant for walled gardens though.

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Winfried Tilanus]

On 1/16/20 10:50 PM, Daniel Gultsch wrote:

Hi,

> I think we are currently in a situation where developers implement and
> deploy experimental XEPs which made us more and more careful of what
> we accept as experimental. When I say clean up I mean advancing
> certain XEPs to draft to get into a situation where developers can
> take the "Do not implement this XEP in production" warning serious
> again because there are enough 'draft' and 'stable' XEPs to choose
> from.

In the discussion up to now, and this is not a specific reaction to this
comment, I am missing the question *why* a XEP doesn't advance.
- does the council need more time to assess it?
- is it abandoned by the author (but still useful)?
- is it incomplete (too many ToDo's)?
- does it have protocol issues?
- are there IP issues?

I would love to see bugtracking against XEP's and the council assigning
labels to bugs when they are blocking propagation to the next stage.
That would make the process clearer for XEP authors and inform
developers on possible issues when implementing experimental XEPs.

(Still, IMHO, it has to be very clear what criteria are used before
accepting a XEP as official XEP and which XEP's are accepted as such and
which not).

Winfried

-- 
privacy strategist & privacy architect
+31.6.23303960
https://www.tilanus.com/
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A Meta-Discussion about the Standards Process

[Dave Cridland]

On Fri, 17 Jan 2020 at 10:26, Daniel Gultsch  wrote:

> have potential to improve the current situation. The problem with the
> status quo of how Council makes its decisions is that it is a
> combination of tribal law and seemingly arbitrary judgment calls. If
> we want to continue with the current status quo we need to codify the
> rules that Council has been following in XEP-0001. To outsiders our
> decisions must not seem arbitrary. If my XEP got rejected I need to
> know why and I need to know that Council followed rules or guidelines
> instead of just not liking me personally. For example, I remember the
> rejection of MUC Light as being highly  controversial and not very
> well received by the authors.[1]
>

(I'll sort of reply to this backwards)

You remember drama because there was - I vetoed that, so I remember it
well. I don't often veto things, at least from my perspective, but I might
be deluding myself.

Moreover, I use the protocol now - we use it for team chats in Pando,
because, as claimed, it works much better than XEP-0045 for mobile, though
in fairness we're not using very much of MUC Light either - it just happens
to be easier to drive form the MongooseIM API. It's also an evolutionary
dead-end, and I haven't changed my mind that it's unsuited to Standards
Track, despite the fact I'm using it. (Widespread support would be quite
convenient to me and my employer, in fact).

I know how frustrating it is to get a veto, as well - I suspect I might
have written more vetoed ProtoXEPs than anyone else, but I can only imagine
it's far worse to have your first attempt as a newcomer rejected seemingly
out of hand.

While I think I use the veto rarely (and I imagine statistics may surprise
me), and I think I'm consistent, I'm fully aware that my consistency is not
consistent with that of others - different Council people apply different,
and entirely personal, rules.

I'm all in favour of codifying the rules, but I think it'd be useful to
understand from current and previous members of Council what they used as
their personal yardsticks, and try to understand what the community at
large thinks Council ought to be thinking about.

Also, I have wildly different ideas about what's acceptable on the
Standards Track compared to off it, and we really don't have much options
but on it now.

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Dave Cridland]

On Fri, 17 Jan 2020 at 10:31, Marvin W  wrote:

> Related to that: If XSF fails to provide what the *majority of users*
> (even if it's a minority of developers) expect them to provide (in terms
> of features or speed of adoption), we'll end up with something like
> WHATWG: an independent working group of the top vendors that don't care
> if their standards get accepted by the XSF because they can basically
> enforce them through their market power. I don't think that's desirable.
>

Well, yes, but the majority of our end-users are probably Fortnite players,
and they're not talking to us.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A Meta-Discussion about the Standards Process

[Marvin W]

On 1/17/20 11:05 AM, Kevin Smith wrote:
> Yes, I agree with what I think you’re saying - if there is a spec published 
> that does what someone needs, they will implement it regardless of what the 
> state says at the top (or any warnings about readiness). The “Inbox+” idea 
> mostly just accepts that and uses the pre-XEP track to make it easy for 
> people to understand the state of things - because as well as the issue that 
> if there’s a spec people need they’ll implement it, I also believe there is 
> confusion because “Well, it’s been published as a XEP”; 

What will make it easier or more obvious for people to understand they
shall not implement a pre-XEP from inbox that we don't already have for
Experimental today?

> I have at least had people ask for things to be implemented (more by users 
> than XMPP aficionados)  because they’re a XEP and therefore they are Good.

I was always under the impression that users ask for features no matter
if they are a XEP. "There is no XEP for it" is rather the lame excuse by
developers to not implement a requested feature. If people ask you to
implement a XEP (being it pre-xep, inbox, experimental, rejected or
deprecated) I'd already classify them as "XMPP aficionados" to some degree.

Related to that: If XSF fails to provide what the *majority of users*
(even if it's a minority of developers) expect them to provide (in terms
of features or speed of adoption), we'll end up with something like
WHATWG: an independent working group of the top vendors that don't care
if their standards get accepted by the XSF because they can basically
enforce them through their market power. I don't think that's desirable.

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Daniel Gultsch]

First of all: People move mountains all the time. That’s how the new
Hong Kong airport got built.

I think that both approaches
* Status quo + Super-Inbox
* Follow XEP-0001

have potential to improve the current situation. The problem with the
status quo of how Council makes its decisions is that it is a
combination of tribal law and seemingly arbitrary judgment calls. If
we want to continue with the current status quo we need to codify the
rules that Council has been following in XEP-0001. To outsiders our
decisions must not seem arbitrary. If my XEP got rejected I need to
know why and I need to know that Council followed rules or guidelines
instead of just not liking me personally. For example, I remember the
rejection of MUC Light as being highly  controversial and not very
well received by the authors.[1]

Codifying our current rules in XEP-0001, even though I believe that
our current rules in combination with Super-Inbox would work out
somewhat OK, is the mountain that *I* don’t want to move.


cheers
Daniel

[1]: Take that with a grain of salt. That was at the time of my very
first Summit and I had just become a member and I might remember drama
where there wasn’t really any drama.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A Meta-Discussion about the Standards Process

[Kevin Smith]

On 17 Jan 2020, at 09:54, Marvin W  wrote:
> 
> On 1/17/20 10:29 AM, Kevin Smith wrote:
>>> I need a feature X *now* and all I see is
>>> an experimental XEP I have two choices; Implement that Experimental
>>> XEP or create something myself.
>> I don’t think making the barrier to entry to Experimental lower (or Draft) 
>> will change that fact, so if this assessment of the cause is right, we’ll 
>> still be in the same position
> 
> I think the important part when having a higher bar on Experimental is
> that it won't solve this issue either. The higher bar already means that
> people start implementing things that are in inbox. This happened for
> example with the Reactions XEP and if I wanted to implement Reactions
> today, I'd certainly use what is in the inbox now. Also aesgcm links are
> widely used while stuck in inbox.
> 
> To phrase it differently:
> 
> Previous way:
> Deemed ready by XSF: Draft+
> People implement: Experimental+
> 
> Current way:
> Deemed ready by XSF: Draft+
> OKish by XSF: Experimental
> People implement: Inbox+
> 
> I don't see any improvement. It will always be the case that some people
> implement the protocols as soon as they are publicly accessible and if
> it turns out those protocols work well enough, others will follow.
> Having a higher bar before the XEP is adopted by XSF will just result in
> less being adopted by XSF and not less (pre-)experimental things being
> implemented.

Yes, I agree with what I think you’re saying - if there is a spec published 
that does what someone needs, they will implement it regardless of what the 
state says at the top (or any warnings about readiness). The “Inbox+” idea 
mostly just accepts that and uses the pre-XEP track to make it easy for people 
to understand the state of things - because as well as the issue that if 
there’s a spec people need they’ll implement it, I also believe there is 
confusion because “Well, it’s been published as a XEP”; I have at least had 
people ask for things to be implemented (more by users than XMPP aficionados)  
because they’re a XEP and therefore they are Good.

I think it might also be easier for us to stick to that process than the 
current one, which experience suggests is easy to let slip.

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Marvin W]

On 1/17/20 10:29 AM, Kevin Smith wrote:
>> I need a feature X *now* and all I see is
>> an experimental XEP I have two choices; Implement that Experimental
>> XEP or create something myself.
> I don’t think making the barrier to entry to Experimental lower (or Draft) 
> will change that fact, so if this assessment of the cause is right, we’ll 
> still be in the same position

I think the important part when having a higher bar on Experimental is
that it won't solve this issue either. The higher bar already means that
people start implementing things that are in inbox. This happened for
example with the Reactions XEP and if I wanted to implement Reactions
today, I'd certainly use what is in the inbox now. Also aesgcm links are
widely used while stuck in inbox.

To phrase it differently:

Previous way:
Deemed ready by XSF: Draft+
People implement: Experimental+

Current way:
Deemed ready by XSF: Draft+
OKish by XSF: Experimental
People implement: Inbox+

I don't see any improvement. It will always be the case that some people
implement the protocols as soon as they are publicly accessible and if
it turns out those protocols work well enough, others will follow.
Having a higher bar before the XEP is adopted by XSF will just result in
less being adopted by XSF and not less (pre-)experimental things being
implemented.

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Kevin Smith]

(Snipping bits that hopefully don’t cause a misrepresentation of Daniel’s views)

On 17 Jan 2020, at 09:18, Daniel Gultsch  wrote:
> It *almost* feels like we shifted our stages to the left were Draft is
> the new Final and experimental is the new Draft. The latter is
> currently less true than the former; However I’m afraid that
> introducing a stage before experimental will make us raise the bar to
> experimental even more and complete this shift.

I won’t pretend that this is impossible.

> I also don’t think that we got here because people didn’t understand
> what Experimental meant but because people had no other choice. I mean
> if I'm a developer, somewhat outside the XSF (and every developer
> starts out like this), and I need a feature X *now* and all I see is
> an experimental XEP I have two choices; Implement that Experimental
> XEP or create something myself.

This is kinda the point I’m (failing to) make(ing) about Muhammad and 
Mountains. I don’t think making the barrier to entry to Experimental lower (or 
Draft) will change that fact, so if this assessment of the cause is right, 
we’ll still be in the same position - if someone wants to implement something 
something that’s a XEP they’ll implement it regardless of the formal state it’s 
in (I hope this isn’t misconstruing what you said). While reducing the number 
of things in the state that we believe isn’t ready to implement will reduce the 
surface for this, I don’t think it fundamentally addresses it.


> The truth is probably somewhere in between people not understanding
> this (and/or at least not seeing the full consequences) and our
> failure to move things to Draft more quickly. In any case I think
> those two factors are reinforcing each other and we need to stop that
> cycle.

Moving things to Draft sooner will reduce the surface, yes, but I’m not sure 
(see above) that it really addresses the issue.


> The answer to "people don’t understand the nuances between our 5
> different stages" can’t be "let's introduce more stages".

I think that’s possibly true - *unless* the reason that people don’t understand 
(or are forced to ignore, whichever) our stages is that our stages don’t map 
cleanly onto people’s expectations, in which case it might be reasonable to 
move us to the mountain.


> On interesting point about the super inbox / non working group draft
> version is that it would probably be easier to fork drafts if the
> original author is unresponsive. For example if draft-kile-mix-01 is
> not moving fast enough I could just create my own
> draft-gultsch-mix-01. However I’m not fully sure if we would want to
> do that in super inbox and/or if we couldn’t just do something similar
> in experimental.

Yes, that’s an interesting thought.

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Daniel Gultsch]

I didn’t want to respond to this last night and then Dave already made
most of the points for me.  (Which however won’t stop me from
repeating some of them.)

Am Do., 16. Jan. 2020 um 22:17 Uhr schrieb Kevin Smith :

> Tidying up the unlawful East cost to make it more like the well-policed and 
> gunless wild West (ok, I’m not going to pretend to be cultured or a student 
> of history) is easier to see (for me) through to the end goals. We got here, 
> at least in part, through people not understanding that Experimental means 
> Experimental, and implementing and putting these things in production anyway 
> - how would we go from here to where that’s not happening? There are also 
> implications on Draft - where Draft’s barrier to entry would have to be 
> lowered in order for implementable XEPs to move in with our friend in the 
> wild West country, or no tidying up is really possible - if things that 
> previously we thought weren’t ready to Draft because there were likely to be 
> further changes that we wouldn’t want to inflict on (informed) production 
> implementations become Draft, what are the implications for the deployments 
> who expect Draft XEPs to be somewhat stable (as now).

I think it would be OK to lower the barrier to Draft from it's status
quo back to what is spelled out in XEP-0001.
Currently the barrier to Draft is crazy high and to me, in practice,
almost indistinguishable from Final.
I think this is evident in two things:
* One of the questions in the Last Call is: Are you *planning* to
implement this. To which we regularly get responses like: I already
have.
* I have never witnessed a XEP actually getting to Final even though
we have multiple Drafts that fulfill the 'implemented in two
implementations' criteria.

It *almost* feels like we shifted our stages to the left were Draft is
the new Final and experimental is the new Draft. The latter is
currently less true than the former; However I’m afraid that
introducing a stage before experimental will make us raise the bar to
experimental even more and complete this shift.

I also don’t think that we got here because people didn’t understand
what Experimental meant but because people had no other choice. I mean
if I'm a developer, somewhat outside the XSF (and every developer
starts out like this), and I need a feature X *now* and all I see is
an experimental XEP I have two choices; Implement that Experimental
XEP or create something myself.
The truth is probably somewhere in between people not understanding
this (and/or at least not seeing the full consequences) and our
failure to move things to Draft more quickly. In any case I think
those two factors are reinforcing each other and we need to stop that
cycle.

The answer to "people don’t understand the nuances between our 5
different stages" can’t be "let's introduce more stages".


On interesting point about the super inbox / non working group draft
version is that it would probably be easier to fork drafts if the
original author is unresponsive. For example if draft-kile-mix-01 is
not moving fast enough I could just create my own
draft-gultsch-mix-01. However I’m not fully sure if we would want to
do that in super inbox and/or if we couldn’t just do something similar
in experimental.


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

Re: [Standards] A Meta-Discussion about the Standards Process

[Dave Cridland]

On Thu, 16 Jan 2020 at 22:15, Peter Saint-Andre  wrote:

> On 1/16/20 2:49 PM, Dave Cridland wrote:
>
> [ historical inaccuracies elided :P ]
>
>
Fake news, doubtless.


> > > Peter Saint-Andre (I think) designed our standards process to
> > avoid the
> > > Internet Draft stage and go straight to the wild-west of
> Experimental,
> > > but it's otherwise the same as the original IETF design.
> >
> > Originally, the Editor (me) accepted anything for publication as a
> JEP,
> > after minimal coherence / formatting checks and IPR assignment. Then
> the
> > Council decided it wanted to act as a gate to publication, which is
> how
> > got here. Instead of adding more epicycles, I propose that we remove
> the
> > one we added. Consider me in favor of the "Daniel Plan".
> >
> > I can easily be persuaded to go for the Florian Plan (or indeed the
> > closely-related Kev Plan), but I rather lean toward the Daniel Plan - as
> > you note, it fits the history of the XSF much better. I would be
> > fascinated to hear the original reasoning for the Council wanting the
> > veto in the first place, and I doubt it has much to do with how it's
> > used now.
>
> Control. Power. The usual suspects. ;-)
>
>
Oh, so my doubts were misplaced? ;-)


> I don't exactly recall - we'd need to look at the list archives. But I'd
> say this happened in 2004 or 2005 because, for instance, XEP-0143 went
> directly to version 0.1 on 2004-09-15 whereas subsequent specs underwent
> several and sometimes multiple revisions based on Council feedback
> before being published as XEPs.
>
>
Interesting; I didn't realise it was that late.


> > My concern is that on several occasions the Council has been the only
> > thing preventing encumbered specifications from entering the Standards
> > Track, so I think this use of the veto is risky to lose entirely.
>
> Did we receive any encumbered specifications before ~2004-2005?
>
>
Probably not; but I wouldn't know, I'm a latecomer from 2006/7. I don't
remember any mention of any.


> Did this issue even arise back then, and if not does it make sense to
> attribute this magical power of saving us from encumbered specifications
> to the Council?
>

It has arisen since, and Council seem to have spotted each case and stopped
it entering the Standards Track.


> How do we determine that specifications are encumbered and do we
> actually need the Council for that?


Well, we need someone to make the decision and take the blame. Some
decisions are easier to make with a voting committee than trying to read
consensus (and who would do that consensus call, anyway?).

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Dave Cridland]

On Thu, 16 Jan 2020 at 22:17, Kevin Smith  wrote:

> I think before glibly agreeing for the sake of harmony, I’d quite like to
> understand what this would entail.
>
>
I think a lot of work. But work that is well worth doing.


> The Kev/Flow plan is, as I have (I think) consistently said, the
> conceptually ‘wrong’ thing to do (although I believe that given human
> nature and where we are that it’s the pragmatic thing to do) - it is,
> though, fairly easy to understand (I think). Get rid of Inbox, make a
> formal protoXEP type that has an identifier (smith-fastening-01 or
> whatever) with no barrier to acceptance but is also not a XEP, and then
> nothing else changes - Council still have a vote on moving to XEP
> (Experimental), and human nature of not understanding why XEP-0258 is fine
> to implement in production, while XEP-0386 must not is allayed because
> XEP-0386 wouldn’t have been such, it would have been bind2-smith-1.0 or
> whatever and clearly distinct.
>

So... Would this mean that Council votes to let others implement? I assume
not, we neither prevent nor force implementation. Or is the move to
Experimental an approval of sorts now? Because if so, what is it an
approval of? Widespread implementation?

I am, I admit, picking holes in this idea - I think it could work, though I
lean toward ensuring Experimental is a "safe space" for experimentation
with XEPs which are candidates for Standardisation.


> Tidying up the unlawful East cost to make it more like the well-policed
> and gunless wild West (ok, I’m not going to pretend to be cultured or a
> student of history) is easier to see (for me) through to the end goals. We
> got here, at least in part, through people not understanding that
> Experimental means Experimental, and implementing and putting these things
> in production anyway - how would we go from here to where that’s not
> happening? There are also implications on Draft - where Draft’s barrier to
> entry would have to be lowered in order for implementable XEPs to move in
> with our friend in the wild West country, or no tidying up is really
> possible - if things that previously we thought weren’t ready to Draft
> because there were likely to be further changes that we wouldn’t want to
> inflict on (informed) production implementations become Draft, what are the
> implications for the deployments who expect Draft XEPs to be somewhat
> stable (as now).
>
>
I actually don't think there's much risk of Draft lowering in quality. We
do tend to be quite picky over Last Calls as it is (just ask poor Daniel
who is suffering through his third with XEP-0363). I do think there's a
risk of making Experimental a higher bar, and then it's harder to see what
Draft really means.


> I’m not in a position where I think the proposal of barrierless (within
> the confines of our submission rules) XEPs is a bad thing, or things moving
> to Draft is bad, or people not implimenting Experimental because it’s an
> experiment is bad - these are all things that seem self-evidently
> reasonable. I don’t see how we get to this land of hope and joy from where
> we are, and I’m concerned that there might be a degree of overoptimism in
> thinking that it’s a tractable problem to change people’s perceptions of
> the states, without having seen a fleshed-out plan for how to achieve it.
> I’d rather we moved that mountain, but I suspect it’s more realistic for us
> to move to it.
>
>
As a concrete suggestion, what about this:

1) We spend the calendar year from this Summit until the next running the
Kev Plan, and simultaneously operating the preparatory step for the Daniel
Plan of aggressively seeking candidates for advancement.
2) In time for the next Summit, we consider whether it worked, and consider
switching to the Daniel Plan, again reviewing at the Summit?


> (That said, if someone *can* come up with such a plausible plan through
> the knock-on stages etc., I think it would probably be a better idea than
> the Kev/Flow plan for the scope of XEP advancements - I still think that
> the pre-XEP stage might be a jolly good way of being able to publish things
> that just shouldn’t be XEPs, e.g. because they require licenses to
> proprietary systems or whatever, but are useful to document with less
> confusion than XEPping them in a different track).
>

I have a feeling that being able to deprecate etc these things is useful
enough to outweigh the downsides, and I think being able to move Standards
Track XEPs into the non-standard Type - and hopefully the other way - would
be useful as well.

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Kevin Smith]

> On 16 Jan 2020, at 22:15, Kevin Smith  wrote:
> 
> On 16 Jan 2020, at 21:50, Daniel Gultsch  > wrote:
>> 
>> Am Do., 16. Jan. 2020 um 21:32 Uhr schrieb Dave Cridland > >:
>>> 
>>> 
>>> 
>>> On Thu, 16 Jan 2020 at 20:55, Daniel Gultsch >> > wrote:
 
 Am Do., 12. Dez. 2019 um 09:24 Uhr schrieb Dave Cridland 
 mailto:d...@cridland.net>>:
 
> 2) The "Daniel Plan", which is to encourage Council to adopt pretty well 
> anything. If this sounds radical to you, it might help if I described it 
> as simply reimposing the de-jure standards process as described in 
> XEP-0001. I can certainly see the attraction, but I also think it ignores 
> the status quo and the problems alluded to above. Most recently suggested 
> by Daniel Gultsch.
 
 If the status quo does not reflect the process described in XEP-0001
 then maybe the status isn’t quo and we should strive to fix that
 instead of changing the process.
 
 If we manage to clean up 'experimental' by advancing what deserves to
 be advanced and documenting issues in widely-deployed but not ready to
 be advanced XEPs I think 'experimental' can become a home for
 controversial[1] XEPs; Maybe even for OMEMO in its current form[2].
>>> 
>>> 
>>> I will very heavily resist us placing anything knowingly encumbered onto 
>>> the Standards Track in any form.
>>> 
 
 After all that state contains a big fat warning saying: "Publication
 as an XMPP Extension Protocol does not imply approval of this proposal
 by the XMPP Standards Foundation". Just because we have seen that
 warning so many times that we have learned to ignore it doesn’t mean
 it's there.
 
 Note that what I’m suggesting here is has an order of operations:
 Clean up experimental first and then, and only if successful, start
 making it the 'everything goes' state[3].
 
>>> 
>>> I don't understand this - if we're making Experimental the wild west (and, 
>>> Peter, I am speaking metaphorically here), then why "clean it up"? I might 
>>> find myself in agreement, mind, I simply don't understand what you mean 
>>> here.
>> 
>> I think we are currently in a situation where developers implement and
>> deploy experimental XEPs which made us more and more careful of what
>> we accept as experimental. When I say clean up I mean advancing
>> certain XEPs to draft to get into a situation where developers can
>> take the "Do not implement this XEP in production" warning serious
>> again because there are enough 'draft' and 'stable' XEPs to choose
>> from.
> 
> I think before glibly agreeing for the sake of harmony, I’d quite like to 
> understand what this would entail. 
> 
> The Kev/Flow plan is, as I have (I think) consistently said, the conceptually 
> ‘wrong’ thing to do (although I believe that given human nature and where we 
> are that it’s the pragmatic thing to do) - it is, though, fairly easy to 
> understand (I think). Get rid of Inbox, make a formal protoXEP type that has 
> an identifier (smith-fastening-01 or whatever) with no barrier to acceptance 
> but is also not a XEP, and then nothing else changes - Council still have a 
> vote on moving to XEP (Experimental), and human nature of not understanding 
> why XEP-0258 is fine to implement in production, while XEP-0386 must not is 
> allayed because XEP-0386 wouldn’t have been such, it would have been 
> bind2-smith-1.0 or whatever and clearly distinct.
> 
> Tidying up the unlawful East cost to make it more like the well-policed and 
> gunless wild West (ok, I’m not going to pretend to be cultured or a student 
> of history) is easier

*harder*. Is *harder* for me to see through.

> to see (for me) through to the end goals. We got here, at least in part, 
> through people not understanding that Experimental means Experimental, and 
> implementing and putting these things in production anyway - how would we go 
> from here to where that’s not happening? There are also implications on Draft 
> - where Draft’s barrier to entry would have to be lowered in order for 
> implementable XEPs to move in with our friend in the wild West country, or no 
> tidying up is really possible - if things that previously we thought weren’t 
> ready to Draft because there were likely to be further changes that we 
> wouldn’t want to inflict on (informed) production implementations become 
> Draft, what are the implications for the deployments who expect Draft XEPs to 
> be somewhat stable (as now).
> 
> I’m not in a position where I think the proposal of barrierless (within the 
> confines of our submission rules) XEPs is a bad thing, or things moving to 
> Draft is bad, or people not implimenting Experimental because it’s an 
> experiment is bad - these are all things that seem self-evidently reasonable. 
> I don’t see how we get to this land of hope and joy from where we are, and 
> 

Re: [Standards] A Meta-Discussion about the Standards Process

[Kevin Smith]

On 16 Jan 2020, at 21:50, Daniel Gultsch  wrote:
> 
> Am Do., 16. Jan. 2020 um 21:32 Uhr schrieb Dave Cridland  >:
>> 
>> 
>> 
>> On Thu, 16 Jan 2020 at 20:55, Daniel Gultsch  wrote:
>>> 
>>> Am Do., 12. Dez. 2019 um 09:24 Uhr schrieb Dave Cridland 
>>> :
>>> 
 2) The "Daniel Plan", which is to encourage Council to adopt pretty well 
 anything. If this sounds radical to you, it might help if I described it 
 as simply reimposing the de-jure standards process as described in 
 XEP-0001. I can certainly see the attraction, but I also think it ignores 
 the status quo and the problems alluded to above. Most recently suggested 
 by Daniel Gultsch.
>>> 
>>> If the status quo does not reflect the process described in XEP-0001
>>> then maybe the status isn’t quo and we should strive to fix that
>>> instead of changing the process.
>>> 
>>> If we manage to clean up 'experimental' by advancing what deserves to
>>> be advanced and documenting issues in widely-deployed but not ready to
>>> be advanced XEPs I think 'experimental' can become a home for
>>> controversial[1] XEPs; Maybe even for OMEMO in its current form[2].
>> 
>> 
>> I will very heavily resist us placing anything knowingly encumbered onto the 
>> Standards Track in any form.
>> 
>>> 
>>> After all that state contains a big fat warning saying: "Publication
>>> as an XMPP Extension Protocol does not imply approval of this proposal
>>> by the XMPP Standards Foundation". Just because we have seen that
>>> warning so many times that we have learned to ignore it doesn’t mean
>>> it's there.
>>> 
>>> Note that what I’m suggesting here is has an order of operations:
>>> Clean up experimental first and then, and only if successful, start
>>> making it the 'everything goes' state[3].
>>> 
>> 
>> I don't understand this - if we're making Experimental the wild west (and, 
>> Peter, I am speaking metaphorically here), then why "clean it up"? I might 
>> find myself in agreement, mind, I simply don't understand what you mean here.
> 
> I think we are currently in a situation where developers implement and
> deploy experimental XEPs which made us more and more careful of what
> we accept as experimental. When I say clean up I mean advancing
> certain XEPs to draft to get into a situation where developers can
> take the "Do not implement this XEP in production" warning serious
> again because there are enough 'draft' and 'stable' XEPs to choose
> from.

I think before glibly agreeing for the sake of harmony, I’d quite like to 
understand what this would entail. 

The Kev/Flow plan is, as I have (I think) consistently said, the conceptually 
‘wrong’ thing to do (although I believe that given human nature and where we 
are that it’s the pragmatic thing to do) - it is, though, fairly easy to 
understand (I think). Get rid of Inbox, make a formal protoXEP type that has an 
identifier (smith-fastening-01 or whatever) with no barrier to acceptance but 
is also not a XEP, and then nothing else changes - Council still have a vote on 
moving to XEP (Experimental), and human nature of not understanding why 
XEP-0258 is fine to implement in production, while XEP-0386 must not is allayed 
because XEP-0386 wouldn’t have been such, it would have been bind2-smith-1.0 or 
whatever and clearly distinct.

Tidying up the unlawful East cost to make it more like the well-policed and 
gunless wild West (ok, I’m not going to pretend to be cultured or a student of 
history) is easier to see (for me) through to the end goals. We got here, at 
least in part, through people not understanding that Experimental means 
Experimental, and implementing and putting these things in production anyway - 
how would we go from here to where that’s not happening? There are also 
implications on Draft - where Draft’s barrier to entry would have to be lowered 
in order for implementable XEPs to move in with our friend in the wild West 
country, or no tidying up is really possible - if things that previously we 
thought weren’t ready to Draft because there were likely to be further changes 
that we wouldn’t want to inflict on (informed) production implementations 
become Draft, what are the implications for the deployments who expect Draft 
XEPs to be somewhat stable (as now).

I’m not in a position where I think the proposal of barrierless (within the 
confines of our submission rules) XEPs is a bad thing, or things moving to 
Draft is bad, or people not implimenting Experimental because it’s an 
experiment is bad - these are all things that seem self-evidently reasonable. I 
don’t see how we get to this land of hope and joy from where we are, and I’m 
concerned that there might be a degree of overoptimism in thinking that it’s a 
tractable problem to change people’s perceptions of the states, without having 
seen a fleshed-out plan for how to achieve it. I’d rather we moved that 
mountain, but I suspect it’s more realistic for us to move to it.

(That said, 

Re: [Standards] A Meta-Discussion about the Standards Process

[Peter Saint-Andre]

On 1/16/20 2:49 PM, Dave Cridland wrote:

[ historical inaccuracies elided :P ]

> > Peter Saint-Andre (I think) designed our standards process to
> avoid the
> > Internet Draft stage and go straight to the wild-west of Experimental,
> > but it's otherwise the same as the original IETF design.
> 
> Originally, the Editor (me) accepted anything for publication as a JEP,
> after minimal coherence / formatting checks and IPR assignment. Then the
> Council decided it wanted to act as a gate to publication, which is how
> got here. Instead of adding more epicycles, I propose that we remove the
> one we added. Consider me in favor of the "Daniel Plan".
> 
> I can easily be persuaded to go for the Florian Plan (or indeed the
> closely-related Kev Plan), but I rather lean toward the Daniel Plan - as
> you note, it fits the history of the XSF much better. I would be
> fascinated to hear the original reasoning for the Council wanting the
> veto in the first place, and I doubt it has much to do with how it's
> used now.

Control. Power. The usual suspects. ;-)

I don't exactly recall - we'd need to look at the list archives. But I'd
say this happened in 2004 or 2005 because, for instance, XEP-0143 went
directly to version 0.1 on 2004-09-15 whereas subsequent specs underwent
several and sometimes multiple revisions based on Council feedback
before being published as XEPs.

> My concern is that on several occasions the Council has been the only
> thing preventing encumbered specifications from entering the Standards
> Track, so I think this use of the veto is risky to lose entirely.

Did we receive any encumbered specifications before ~2004-2005?

Did this issue even arise back then, and if not does it make sense to
attribute this magical power of saving us from encumbered specifications
to the Council?

How do we determine that specifications are encumbered and do we
actually need the Council for that?

Peter

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Dave Cridland]

On Thu, 16 Jan 2020 at 21:50, Daniel Gultsch  wrote:

> Am Do., 16. Jan. 2020 um 21:32 Uhr schrieb Dave Cridland <
> d...@cridland.net>:
> >
> >
> >
> > On Thu, 16 Jan 2020 at 20:55, Daniel Gultsch  wrote:
> >>
> >> Am Do., 12. Dez. 2019 um 09:24 Uhr schrieb Dave Cridland <
> d...@cridland.net>:
> >>
> >> > 2) The "Daniel Plan", which is to encourage Council to adopt pretty
> well anything. If this sounds radical to you, it might help if I described
> it as simply reimposing the de-jure standards process as described in
> XEP-0001. I can certainly see the attraction, but I also think it ignores
> the status quo and the problems alluded to above. Most recently suggested
> by Daniel Gultsch.
> >>
> >> If the status quo does not reflect the process described in XEP-0001
> >> then maybe the status isn’t quo and we should strive to fix that
> >> instead of changing the process.
> >>
> >> If we manage to clean up 'experimental' by advancing what deserves to
> >> be advanced and documenting issues in widely-deployed but not ready to
> >> be advanced XEPs I think 'experimental' can become a home for
> >> controversial[1] XEPs; Maybe even for OMEMO in its current form[2].
> >
> >
> > I will very heavily resist us placing anything knowingly encumbered onto
> the Standards Track in any form.
> >
> >>
> >> After all that state contains a big fat warning saying: "Publication
> >> as an XMPP Extension Protocol does not imply approval of this proposal
> >> by the XMPP Standards Foundation". Just because we have seen that
> >> warning so many times that we have learned to ignore it doesn’t mean
> >> it's there.
> >>
> >> Note that what I’m suggesting here is has an order of operations:
> >> Clean up experimental first and then, and only if successful, start
> >> making it the 'everything goes' state[3].
> >>
> >
> > I don't understand this - if we're making Experimental the wild west
> (and, Peter, I am speaking metaphorically here), then why "clean it up"? I
> might find myself in agreement, mind, I simply don't understand what you
> mean here.
>
> I think we are currently in a situation where developers implement and
> deploy experimental XEPs which made us more and more careful of what
> we accept as experimental. When I say clean up I mean advancing
> certain XEPs to draft to get into a situation where developers can
> take the "Do not implement this XEP in production" warning serious
> again because there are enough 'draft' and 'stable' XEPs to choose
> from.


Yes, understood, and I fully agree.

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Daniel Gultsch]

Am Do., 16. Jan. 2020 um 21:32 Uhr schrieb Dave Cridland :
>
>
>
> On Thu, 16 Jan 2020 at 20:55, Daniel Gultsch  wrote:
>>
>> Am Do., 12. Dez. 2019 um 09:24 Uhr schrieb Dave Cridland :
>>
>> > 2) The "Daniel Plan", which is to encourage Council to adopt pretty well 
>> > anything. If this sounds radical to you, it might help if I described it 
>> > as simply reimposing the de-jure standards process as described in 
>> > XEP-0001. I can certainly see the attraction, but I also think it ignores 
>> > the status quo and the problems alluded to above. Most recently suggested 
>> > by Daniel Gultsch.
>>
>> If the status quo does not reflect the process described in XEP-0001
>> then maybe the status isn’t quo and we should strive to fix that
>> instead of changing the process.
>>
>> If we manage to clean up 'experimental' by advancing what deserves to
>> be advanced and documenting issues in widely-deployed but not ready to
>> be advanced XEPs I think 'experimental' can become a home for
>> controversial[1] XEPs; Maybe even for OMEMO in its current form[2].
>
>
> I will very heavily resist us placing anything knowingly encumbered onto the 
> Standards Track in any form.
>
>>
>> After all that state contains a big fat warning saying: "Publication
>> as an XMPP Extension Protocol does not imply approval of this proposal
>> by the XMPP Standards Foundation". Just because we have seen that
>> warning so many times that we have learned to ignore it doesn’t mean
>> it's there.
>>
>> Note that what I’m suggesting here is has an order of operations:
>> Clean up experimental first and then, and only if successful, start
>> making it the 'everything goes' state[3].
>>
>
> I don't understand this - if we're making Experimental the wild west (and, 
> Peter, I am speaking metaphorically here), then why "clean it up"? I might 
> find myself in agreement, mind, I simply don't understand what you mean here.

I think we are currently in a situation where developers implement and
deploy experimental XEPs which made us more and more careful of what
we accept as experimental. When I say clean up I mean advancing
certain XEPs to draft to get into a situation where developers can
take the "Do not implement this XEP in production" warning serious
again because there are enough 'draft' and 'stable' XEPs to choose
from.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A Meta-Discussion about the Standards Process

[Dave Cridland]

On Thu, 16 Jan 2020 at 21:18, Peter Saint-Andre  wrote:

> On 12/13/19 6:58 AM, Dave Cridland wrote:
> >
> >
> > On Thu, 12 Dec 2019 at 16:41, Daniel Gultsch  > > wrote:
> >
> > I mean correct me if I'm wrong but the IETF seems to be doing fine
> > with just two stages.
> >
> >
> > Some history...
> >
> > The IETF used to have, essentially, three stages. Proposed Standard,
> > Draft Standard, and Internet Standard - the latter getting a STD number
> > as well as the RFC number. PS was the wild west,
>
> Actually, the wild west was not so wild. [1]
>
>
I do miss your injections of culture and history; the frontier west was
indeed law-abiding compared to the anarchy of the east coast cities, and
larger towns sensibly prohibited firearms like real civilisations. ;-)


> > with (fairly) low
> > requirements.
> >
> > Then they formalized the step before, Internet Drafts, and
> > gradually the Proposed Standard quality (and gating function by the
> > IESG) improved, to the point where it was felt that there was an
> > additional stage that added little, so they dropped it.
> >
> > Peter Saint-Andre (I think) designed our standards process to avoid the
> > Internet Draft stage and go straight to the wild-west of Experimental,
> > but it's otherwise the same as the original IETF design.
>
> Originally, the Editor (me) accepted anything for publication as a JEP,
> after minimal coherence / formatting checks and IPR assignment. Then the
> Council decided it wanted to act as a gate to publication, which is how
> got here. Instead of adding more epicycles, I propose that we remove the
> one we added. Consider me in favor of the "Daniel Plan".
>

I can easily be persuaded to go for the Florian Plan (or indeed the
closely-related Kev Plan), but I rather lean toward the Daniel Plan - as
you note, it fits the history of the XSF much better. I would be fascinated
to hear the original reasoning for the Council wanting the veto in the
first place, and I doubt it has much to do with how it's used now.

My concern is that on several occasions the Council has been the only thing
preventing encumbered specifications from entering the Standards Track, so
I think this use of the veto is risky to lose entirely.

But I would be perfectly fine with restricting the veto to be only for
enforcing our own documented policies (and if we introduce another XEP Type
that has different policies, that reason might disappear for that Type
entirely).

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Dave Cridland]

On Thu, 16 Jan 2020 at 20:55, Daniel Gultsch  wrote:

> Am Do., 12. Dez. 2019 um 09:24 Uhr schrieb Dave Cridland <
> d...@cridland.net>:
>
> > 2) The "Daniel Plan", which is to encourage Council to adopt pretty well
> anything. If this sounds radical to you, it might help if I described it as
> simply reimposing the de-jure standards process as described in XEP-0001. I
> can certainly see the attraction, but I also think it ignores the status
> quo and the problems alluded to above. Most recently suggested by Daniel
> Gultsch.
>
> If the status quo does not reflect the process described in XEP-0001
> then maybe the status isn’t quo and we should strive to fix that
> instead of changing the process.
>
> If we manage to clean up 'experimental' by advancing what deserves to
> be advanced and documenting issues in widely-deployed but not ready to
> be advanced XEPs I think 'experimental' can become a home for
> controversial[1] XEPs; Maybe even for OMEMO in its current form[2].
>

I will very heavily resist us placing anything knowingly encumbered onto
the Standards Track in any form.


> After all that state contains a big fat warning saying: "Publication
> as an XMPP Extension Protocol does not imply approval of this proposal
> by the XMPP Standards Foundation". Just because we have seen that
> warning so many times that we have learned to ignore it doesn’t mean
> it's there.
>
> Note that what I’m suggesting here is has an order of operations:
> Clean up experimental first and then, and only if successful, start
> making it the 'everything goes' state[3].
>
>
I don't understand this - if we're making Experimental the wild west (and,
Peter, I am speaking metaphorically here), then why "clean it up"? I might
find myself in agreement, mind, I simply don't understand what you mean
here.


> cheers
> Daniel
>
>
> [1]: For a wide variety of controversial
> [2]: In the case of OMEMO we could introduce a second warning
> mentioning the issues with the copyright.
> [3]: For a still reasonable definition of everything
> ___
> 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] A Meta-Discussion about the Standards Process

[Peter Saint-Andre]

On 12/13/19 6:58 AM, Dave Cridland wrote:
> 
> 
> On Thu, 12 Dec 2019 at 16:41, Daniel Gultsch  > wrote:
> 
> I mean correct me if I'm wrong but the IETF seems to be doing fine
> with just two stages.
> 
> 
> Some history...
> 
> The IETF used to have, essentially, three stages. Proposed Standard,
> Draft Standard, and Internet Standard - the latter getting a STD number
> as well as the RFC number. PS was the wild west,

Actually, the wild west was not so wild. [1]

> with (fairly) low
> requirements. 
>
> Then they formalized the step before, Internet Drafts, and
> gradually the Proposed Standard quality (and gating function by the
> IESG) improved, to the point where it was felt that there was an
> additional stage that added little, so they dropped it.
> 
> Peter Saint-Andre (I think) designed our standards process to avoid the
> Internet Draft stage and go straight to the wild-west of Experimental,
> but it's otherwise the same as the original IETF design.

Originally, the Editor (me) accepted anything for publication as a JEP,
after minimal coherence / formatting checks and IPR assignment. Then the
Council decided it wanted to act as a gate to publication, which is how
got here. Instead of adding more epicycles, I propose that we remove the
one we added. Consider me in favor of the "Daniel Plan".

Peter

[1] https://www.independent.org/publications/tir/article.asp?id=552
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A Meta-Discussion about the Standards Process

[Daniel Gultsch]

Am Do., 12. Dez. 2019 um 09:24 Uhr schrieb Dave Cridland :

> 2) The "Daniel Plan", which is to encourage Council to adopt pretty well 
> anything. If this sounds radical to you, it might help if I described it as 
> simply reimposing the de-jure standards process as described in XEP-0001. I 
> can certainly see the attraction, but I also think it ignores the status quo 
> and the problems alluded to above. Most recently suggested by Daniel Gultsch.

If the status quo does not reflect the process described in XEP-0001
then maybe the status isn’t quo and we should strive to fix that
instead of changing the process.

If we manage to clean up 'experimental' by advancing what deserves to
be advanced and documenting issues in widely-deployed but not ready to
be advanced XEPs I think 'experimental' can become a home for
controversial[1] XEPs; Maybe even for OMEMO in its current form[2].
After all that state contains a big fat warning saying: "Publication
as an XMPP Extension Protocol does not imply approval of this proposal
by the XMPP Standards Foundation". Just because we have seen that
warning so many times that we have learned to ignore it doesn’t mean
it's there.

Note that what I’m suggesting here is has an order of operations:
Clean up experimental first and then, and only if successful, start
making it the 'everything goes' state[3].

cheers
Daniel


[1]: For a wide variety of controversial
[2]: In the case of OMEMO we could introduce a second warning
mentioning the issues with the copyright.
[3]: For a still reasonable definition of everything
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A Meta-Discussion about the Standards Process

[Florian Schmaus]

Thanks Dave for bringing this up. It is something I believe we really
could, should and must do better.

There are two aspects to this: The phase (I) before a XEP gets first
presented to council, and the phase (II) after it got "accepted" (by
council). Both phases can and should be changed to improve the XEP
development process and encourage collaboration. But we mostly can
discuss and improve them separately.

Regarding (I):
Right now new XEPs get developed in various private or public
repositories. They do not have a stable URL to reference them, nor are
they under the XSF IPR rules. I would like the XSF to adopt a process
akin to IETF's Internet Draft (ID) process. This could/would include:

- Everyone can create a ProtoXEP, it just has to pass basic lint checks
- You get a unique name for it, and a stable URL
- Revisions are immutable and have a stable name/URL
- There is no requirement for namespace bumps on backwards incompatible
changes
- No XSF registry entry is performed
- XSF IPR rules apply
- It is made very obvious that this is an unaccepted, not endorsed,
early-stage protocol not for production environments

I do have some concrete ideas how to model the process with the existing
tools and infrastructure, but I don't feel like we should discuss prior
finding a common ground what we want.

Regarding (II):
This phase also has currently some issues, but they are IMHO far less
important than fixing (I). Nevertheless we really should rename 'draft'
to something else, e.g. 'stable'. Because, and I believe I am not the
only one, 'draft' is what I think of XEPs in (I).
Besides that, I'd also like council to really think about blocking a XEP
from becoming 'Experimental'. Duplicate functionally should not always
be a reason to block, sometimes we may simply want to experiment with a
different solution for a problem. And a personal antipathy against a
certain technology should also not be a reason to block a XEP from
entering 'experimental'. After all, it is not just the council that
decides what gets implemented in the wild, the developers have also a
say in here. I feel like in the past the distance between council and
developers has increased. And that is something we really should avoid,
as I do think council's and the community (last calls) review process is
 beneficial. So we should focus on how to encourage collaboration
between council and developers.


As a related node: I also believe we are currently lacking a process for
collecting breaking changes in (II) in order to minimize namespace bumps.

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Dave Cridland]

On Thu, 12 Dec 2019 at 16:41, Daniel Gultsch  wrote:

> I mean correct me if I'm wrong but the IETF seems to be doing fine
> with just two stages.
>
>
Some history...

The IETF used to have, essentially, three stages. Proposed Standard, Draft
Standard, and Internet Standard - the latter getting a STD number as well
as the RFC number. PS was the wild west, with (fairly) low requirements.
Then they formalized the step before, Internet Drafts, and gradually the
Proposed Standard quality (and gating function by the IESG) improved, to
the point where it was felt that there was an additional stage that added
little, so they dropped it.

Peter Saint-Andre (I think) designed our standards process to avoid the
Internet Draft stage and go straight to the wild-west of Experimental, but
it's otherwise the same as the original IETF design.

So currently, the IETF has three stages, one being a formalized pre-RFC
stage very close to the Experimental stage. We have three as well, being
ahead of the curve, though the IETF ended up dropping Draft Standard
whereas we dropped the Internet-Draft equivalent.

The difference is that there are two types of Internet Draft (that we care
about here), which is "Individual I-Ds" and "Working Group I-Ds". The
latter require formal adoption by the Working Group. The XSF is (roughly)
modelled as a "Working Group in Exile", which is one of the reasons I talk
about "Adopting a ProtoXEP".

> 2) The "Daniel Plan", which is to encourage Council to adopt pretty well
> anything. If this sounds radical to you, it might help if I described it as
> simply reimposing the de-jure standards process as described in XEP-0001. I
> can certainly see the attraction, but I also think it ignores the status
> quo and the problems alluded to above. Most recently suggested by Daniel
> Gultsch.
>
> In a way it doesn’t really matter if we introduce a new Florian Stage
> or if we reuse the existing Experimental stage for that purpose. In
> both cases we somehow have to deal with the status quo. There are a
> number of XEPs currently in Experimental that certainly belong into
> 'Florian'. (I'm going to follow Dave’s example of not providing
> examples.)
>
>
Taking that to mean "There are a number of XEPs which are 'wild west'
territory", yes.


> But that's to me is one of the underlying issues here; While I can
> certainly see why Council would require a certain readiness of a XEP
> before giving it a number, that quality measurement has been applied
> very unevenly in the past. There are *a bunch* of XEPs that literally
> have the text 'TODO' in them.
>
>
I think having TODO is actually fine - my concern is the unevenness.


> Which brings us to:
>
>
> > b) We have to, in particular, codify what each transition means, and
> therefore tighten up Council's veto-for-any-reason here. I don't mean that
> we remove any judgement calls on the part of Council, but I do mean that we
> should create a yardstick on what constitutes a "usual" versus "unusual"
> veto.
>
> Yes I agree with that. More transparent and fairer processing would
> certainly eliminate the feeling of XEP authors to retry after the next
> council has been elected.
>
>
Right.

I think my criteria are:

* Is the scope of this XEP within the scope of the XSF's expertise?
* Could this XEP [eventually] progress to Final?
* Would we want it to?

I think that much is relatively uncontroversial.

The problem is I have further considerations in play, based on past
experiences:

* Do I have a fair idea of what will be needed to get it through to Final?
* Are these changes likely to occur?

I'm naturally more confident in adopting a ProtoXEP where I'm confident in
the answers there.

Sadly, it's unlikely that a given ProtoXEP will hit Last Call in the same
Council session, and I can't bind a future Council to a condition on that
transition, so this becomes largely guesswork. I suspect this is where
Council's more controversial decisions originate.

Another aspect of this is that I need to get a clear understanding of what
the scope of a proposal is, and that can often be unclear.

I suspect we could make vetos much less common if we were more willing to
kill XEPs on Last Call or Draft.


> I feel like only having two stages (Draft and stable) would help with
> that; because it is pretty obvious that for it being stable it has to
> be stable.
>

Hmmm. Two stages is very likely to be insufficient. That would collapse
Draft and Final, and I think these (or rather, the transitions between
them) are radically different.

Experimental to Draft says "We think this is ready for wide adoption, and
it's unlikely to change".

Draft to Final says "We think this has been widely deployed and we're
confident it won't change".

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Daniel Gultsch]

Am Do., 12. Dez. 2019 um 09:24 Uhr schrieb Dave Cridland :

> 1) The "Florian Plan" - introduce a phase prior to Experimental, wherein a 
> XEP is semi-adopted but remains without a number. This somewhat happens 
> anyway, but it does so outside our IPR rules, so arguably this is a case of 
> formalizing the status quo to some degree. On the other hand, it abandons 
> anything Experimental about Experimental. I'm calling this the Florian Plan 
> just because Florian Schmaus has been a vocal proponent - but he's far from 
> the only one.

What bothers me about the Florian Plan is that it introduces an
*additional* step to what in my view is already way too many steps.
Ideally what I want is a 'florian stage' (I was tempted to call it
draft stage but unfortunately we already have a stage called 'draft')
and a stable 'stage'. I don’t see why we need a lot in between.
(Maybe; we might want to hold on to the 'in review' stage; but in the
past we haven’t been very thoroughly with actually moving XEPs in and
out of that 'in review' stage.

I mean correct me if I'm wrong but the IETF seems to be doing fine
with just two stages.

>
> 2) The "Daniel Plan", which is to encourage Council to adopt pretty well 
> anything. If this sounds radical to you, it might help if I described it as 
> simply reimposing the de-jure standards process as described in XEP-0001. I 
> can certainly see the attraction, but I also think it ignores the status quo 
> and the problems alluded to above. Most recently suggested by Daniel Gultsch.

In a way it doesn’t really matter if we introduce a new Florian Stage
or if we reuse the existing Experimental stage for that purpose. In
both cases we somehow have to deal with the status quo. There are a
number of XEPs currently in Experimental that certainly belong into
'Florian'. (I'm going to follow Dave’s example of not providing
examples.)

But that's to me is one of the underlying issues here; While I can
certainly see why Council would require a certain readiness of a XEP
before giving it a number, that quality measurement has been applied
very unevenly in the past. There are *a bunch* of XEPs that literally
have the text 'TODO' in them.

Which brings us to:


> b) We have to, in particular, codify what each transition means, and 
> therefore tighten up Council's veto-for-any-reason here. I don't mean that we 
> remove any judgement calls on the part of Council, but I do mean that we 
> should create a yardstick on what constitutes a "usual" versus "unusual" veto.

Yes I agree with that. More transparent and fairer processing would
certainly eliminate the feeling of XEP authors to retry after the next
council has been elected.

I feel like only having two stages (Draft and stable) would help with
that; because it is pretty obvious that for it being stable it has to
be stable.

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

Re: [Standards] A Meta-Discussion about the Standards Process

[Kevin Smith]

On 12 Dec 2019, at 09:22, Dave Cridland  wrote:
> 
> Many moons past, we had a clever idea.
> 
> What we thought was that we should change the XML namespace system we used - 
> previously, XEPs had been allocated a namespace when adopted, and they stuck 
> with this namespace throughout. Sometimes this broke things during 
> Experimental (indeed, if a XEP had to change in Draft, it'd break things 
> then, too). As a result, people were very shy of implementing anything in 
> Experimental, and this was a problem. Also a problem was that people who did 
> take the plunge on Experimental could end up affecting people who had waited 
> for Draft.
> 
> We initially changed it to a URN, "urn:xmpp:tmp:XYZ". This meant that we 
> could go wild during Experimental, but then change to "urn:xmpp:XYZ" on 
> Draft, stabilising the XEP. While this meant that people who waited for Draft 
> were fine, it still meant that using a "tmp" namespace was a wild west.
> 
> Our final change was that we introduced "versioned" namespaces. Essentially, 
> we stopped being so proud about the final namespace, and just used a prefix 
> to generate new namespaces for a XEP, changing the namespace any time an 
> incompatible change was introduced. We've got so used to this we often change 
> namespace when we shouldn't, frankly, but it's still better than the wild 
> west.
> 
> The effect this has had, though, goes beyond merely allowing safe 
> Experimentation during Experimental - instead, we've a number of XEPs that 
> Council has "allowed in", but have resulted in such widespread implementation 
> and deployment during Experimental that we cannot meaningfully change them 
> without heavy disruption. Meanwhile, the "rules", such as they are, for 
> adopting Experimental do not really reflect that people can safely implement 
> and deploy, from an interoperability point of view. This has lead to another 
> problem, wherein XEPs are adopted in a rough state, but stay rough and the 
> proponents of the XEP never bother changing the XEP. I could give concrete 
> examples of both cases, but I suspect that would only serve to debate whether 
> these are indeed correct - instead I'll leave people to make up their own 
> minds. In any case, the effect of this has been that Council are quite 
> reticent about adopting Experimental XEPs.
> 
> To address these problems, I see several possibilities. I'm putting these in 
> no particular order, because I'm personally conflicted on which, if any, are 
> the right solution, but I hope these can be an interesting start point.
> 
> 1) The "Florian Plan" - introduce a phase prior to Experimental, wherein a 
> XEP is semi-adopted but remains without a number. This somewhat happens 
> anyway, but it does so outside our IPR rules, so arguably this is a case of 
> formalizing the status quo to some degree. On the other hand, it abandons 
> anything Experimental about Experimental. I'm calling this the Florian Plan 
> just because Florian Schmaus has been a vocal proponent - but he's far from 
> the only one.
> 
> 2) The "Daniel Plan", which is to encourage Council to adopt pretty well 
> anything. If this sounds radical to you, it might help if I described it as 
> simply reimposing the de-jure standards process as described in XEP-0001. I 
> can certainly see the attraction, but I also think it ignores the status quo 
> and the problems alluded to above. Most recently suggested by Daniel Gultsch.
> 
> 3) Something Else. We could introduce an additional phase *with* a number, 
> for example, or we could decide the problems are outliers and do nothing.
> 
> While I don't have any particular opinion about what solution, if any, to 
> choose, I do think we have to address a couple of issues:
> 
> a) We have to define what our standards process actually is. I don't mind if 
> that means we change our standards process to match our documentation, or we 
> change the documentation to match the process, or a mixture.
> 
> b) We have to, in particular, codify what each transition means, and 
> therefore tighten up Council's veto-for-any-reason here. I don't mean that we 
> remove any judgement calls on the part of Council, but I do mean that we 
> should create a yardstick on what constitutes a "usual" versus "unusual" veto.
> 
> Finally, whatever we choose, we should make that choice by considering 
> carefully the outcome we desire. The namespace changes we made - which 
> contributed to the current state - were made in good faith, and we never 
> foresaw what effect they'd have over the years.
> 
> Thanks for reading this wall of text,

To my mind, given where we are, I don’t see a way out of this unless we have a 
stage of the process where we can accept under XSF IPR something that we know 
needs significant changes before it’s advancable. I believe that having such 
things published is good, but we don’t currently have such a space (we do on 
paper - Experimental - but as you say, reality is far removed 

[Standards] A Meta-Discussion about the Standards Process

[Dave Cridland]

Many moons past, we had a clever idea.

What we thought was that we should change the XML namespace system we used
- previously, XEPs had been allocated a namespace when adopted, and they
stuck with this namespace throughout. Sometimes this broke things during
Experimental (indeed, if a XEP had to change in Draft, it'd break things
then, too). As a result, people were very shy of implementing anything in
Experimental, and this was a problem. Also a problem was that people who
did take the plunge on Experimental could end up affecting people who had
waited for Draft.

We initially changed it to a URN, "urn:xmpp:tmp:XYZ". This meant that we
could go wild during Experimental, but then change to "urn:xmpp:XYZ" on
Draft, stabilising the XEP. While this meant that people who waited for
Draft were fine, it still meant that using a "tmp" namespace was a wild
west.

Our final change was that we introduced "versioned" namespaces.
Essentially, we stopped being so proud about the final namespace, and just
used a prefix to generate new namespaces for a XEP, changing the namespace
any time an incompatible change was introduced. We've got so used to this
we often change namespace when we shouldn't, frankly, but it's still better
than the wild west.

The effect this has had, though, goes beyond merely allowing safe
Experimentation during Experimental - instead, we've a number of XEPs that
Council has "allowed in", but have resulted in such widespread
implementation and deployment during Experimental that we cannot
meaningfully change them without heavy disruption. Meanwhile, the "rules",
such as they are, for adopting Experimental do not really reflect that
people can safely implement and deploy, from an interoperability point of
view. This has lead to another problem, wherein XEPs are adopted in a rough
state, but stay rough and the proponents of the XEP never bother changing
the XEP. I could give concrete examples of both cases, but I suspect that
would only serve to debate whether these are indeed correct - instead I'll
leave people to make up their own minds. In any case, the effect of this
has been that Council are quite reticent about adopting Experimental XEPs.

To address these problems, I see several possibilities. I'm putting these
in no particular order, because I'm personally conflicted on which, if any,
are the right solution, but I hope these can be an interesting start point.

1) The "Florian Plan" - introduce a phase prior to Experimental, wherein a
XEP is semi-adopted but remains without a number. This somewhat happens
anyway, but it does so outside our IPR rules, so arguably this is a case of
formalizing the status quo to some degree. On the other hand, it abandons
anything Experimental about Experimental. I'm calling this the Florian Plan
just because Florian Schmaus has been a vocal proponent - but he's far from
the only one.

2) The "Daniel Plan", which is to encourage Council to adopt pretty well
anything. If this sounds radical to you, it might help if I described it as
simply reimposing the de-jure standards process as described in XEP-0001. I
can certainly see the attraction, but I also think it ignores the status
quo and the problems alluded to above. Most recently suggested by Daniel
Gultsch.

3) Something Else. We could introduce an additional phase *with* a number,
for example, or we could decide the problems are outliers and do nothing.

While I don't have any particular opinion about what solution, if any, to
choose, I do think we have to address a couple of issues:

a) We have to define what our standards process actually is. I don't mind
if that means we change our standards process to match our documentation,
or we change the documentation to match the process, or a mixture.

b) We have to, in particular, codify what each transition means, and
therefore tighten up Council's veto-for-any-reason here. I don't mean that
we remove any judgement calls on the part of Council, but I do mean that we
should create a yardstick on what constitutes a "usual" versus "unusual"
veto.

Finally, whatever we choose, we should make that choice by considering
carefully the outcome we desire. The namespace changes we made - which
contributed to the current state - were made in good faith, and we never
foresaw what effect they'd have over the years.

Thanks for reading this wall of text,

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