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] LAST CALL: XEP-0363 (HTTP File Upload)

[Ruslan Marchenko]

Am 14.01.2020 um 22:41 schrieb Jonas Schäfer:

This message constitutes notice of a Last Call for comments on XEP-0363. The
Last Call was restarted after the Council election, because the previous
Council did not vote on the ongoing LC.

Title: HTTP File Upload
Abstract:
This specification defines a protocol to request permissions from
another entity to upload a file to a specific path on an HTTP server
and at the same time receive a URL from which that file can later be
downloaded again.

URL: https://xmpp.org/extensions/xep-0363.html

This Last Call begins today and shall end at the close of business on
2020-01-28.

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?

Yes

2. Does the specification solve the problem stated in the introduction
and requirements?

Yes

3. Do you plan to implement this specification in your code? If not,
why not?

Yes (implemented)

4. Do you have any security concerns related to this specification?

No

5. Is the specification accurate and clearly written?

Yes

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-0363 (HTTP File Upload)

[Jonas Schäfer]

14 Jan 2020 10:41:23 pm Jonas Schäfer :

> This message constitutes notice of a Last Call for comments on XEP-0363. The
> Last Call was restarted after the Council election, because the previous
> Council did not vote on the ongoing LC.
>
> Title: HTTP File Upload
> Abstract:
> This specification defines a protocol to request permissions from
> another entity to upload a file to a specific path on an HTTP server
> and at the same time receive a URL from which that file can later be
> downloaded again.
>
> URL: https://xmpp.org/extensions/xep-0363.html
>
> This Last Call begins today and shall end at the close of business on
> 2020-01-28.
>
> 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?

Yes. While we have Jingle FT for peer-to-peer file transfer, there is no 
trivial, specified or widely deployed way for peer-to-multipeer transfer. This 
XEP provides that feature.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Yes. The awkward wording of the last Requirement can easily be fixed in Draft.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

aioxmpp has support for it, I built a few tools around it, and I think I even 
added support in JabberCat.

> 4. Do you have any security concerns related to this specification?

None above and beyond what's already in the document.

> 5. Is the specification accurate and clearly written?

Yes.

> Your feedback is appreciated!
>


--
Jonas Schäfer
This was sent from mobile, and I'm not good with those. Sorry for brevity and 
such.

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

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Dave Cridland]

On Tue, 14 Jan 2020 at 21:41, Jonas Schäfer  wrote:

> This message constitutes notice of a Last Call for comments on XEP-0363.
> The
> Last Call was restarted after the Council election, because the previous
> Council did not vote on the ongoing LC.
>
> Title: HTTP File Upload
> Abstract:
> This specification defines a protocol to request permissions from
> another entity to upload a file to a specific path on an HTTP server
> and at the same time receive a URL from which that file can later be
> downloaded again.
>
> URL: https://xmpp.org/extensions/xep-0363.html
>
> This Last Call begins today and shall end at the close of business on
> 2020-01-28.
>
> 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?
>
>
Yes. While there is some overlap between this specification and Jingle FT,
there is no particular reason why these two cannot be used in a useful
combination in the future.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
>
I'm not convinced the last bullet point is a requirement, actually, but if
it is it is not met.

I think it would be more useful to move this bullet into the Security
Considerations.


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
Not currently; while we move images around we have rather higher
requirements on access control as our images contain sensitive patient
data, and the simplistic approach taken here is insufficient. However,
there are multiple ways to address this and we might revisit.


> 4. Do you have any security concerns related to this specification?
>
>
As mentioned above, I don't think "weak security" is a requirement as such,
and the Security Considerations do not actually make it explicit that this
is the model. It would seem more useful to move that bullet into Security
Considerations and rephrase it slightly.


> 5. Is the specification accurate and clearly written?
>

Yes - and incidentally vastly improved since it's original Last Call.

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

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Holger Weiß]

* Jonas Schäfer  [2020-01-14 22:41]:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

As far as I can see, it's currently our only solution for media sharing
that works reliably with offline recipients, multiple devices, and group
chats.  Similar functionalty could be built using Jingle File Transfer,
but we're probably far away from having this properly spec'ed and
implemented.

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Yes.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

I've implemented it (server-side).

> 4. Do you have any security concerns related to this specification?

No.

> 5. Is the specification accurate and clearly written?

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

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Guus der Kinderen]

On Tue, 14 Jan 2020 at 22:42, Jonas Schäfer  wrote:

> This message constitutes notice of a Last Call for comments on XEP-0363.
> The
> Last Call was restarted after the Council election, because the previous
> Council did not vote on the ongoing LC.
>
> Title: HTTP File Upload
> Abstract:
> This specification defines a protocol to request permissions from
> another entity to upload a file to a specific path on an HTTP server
> and at the same time receive a URL from which that file can later be
> downloaded again.
>
> URL: https://xmpp.org/extensions/xep-0363.html
>
> This Last Call begins today and shall end at the close of business on
> 2020-01-28.
>
> 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?
>
>
Functionally, existing specs cover "transferring data". This protocol,
however, fill the gap of the unavailability of one such protocol that's
easily implemented/adopted.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
> Yes - the last requirement is worded a bit awkwardly perhaps (not doing
something makes for a weird requirement).


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
I have (server-sided)


> 4. Do you have any security concerns related to this specification?
>
>
None other than that are explicitly stated in the specification.


> 5. Is the specification accurate and clearly written?
>
> Yes


> 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-0363 (HTTP File Upload)

[Daniel Gultsch]

The previous last call for this was mostly ignored; which I’m
interpreting as most people are generally happy with this XEP. However
for due process I think we need to collect some feedback so let me
start with mine.

Am Di., 14. Jan. 2020 um 21:43 Uhr schrieb Jonas Schäfer :

> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Yes and no. There is arguably some overlap with Jingle File Transfer.
However Jingle FT is still experimental (or technically even deferred
at this point) and much much harder to implement.

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Yes

> 3. Do you plan to implement this specification in your code? If not,
> why not?

I have implemented it.

> 4. Do you have any security concerns related to this specification?

No

> 5. Is the specification accurate and clearly written?

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