Re: [Standards] XEP-0369: MIX - About create a room/channel

[Ralph Meijer]

On April 23, 2018 5:34:06 PM GMT+02:00, Steve Kille  
wrote:
>
>
>> -Original Message-
>> From: Manuel Rubio 
>> Sent: 23 April 2018 16:12
>> To: XMPP Standards 
>> Cc: Steve Kille 
>> Subject: Re: [Standards] XEP-0369: MIX - About create a room/channel
>> 
>> Hi Steve,
>> 
>> thanks for your answers. About one I think was omitted, if I (hag66)
>create a
>> channel saying the owners are "hecate" and "greymalkin", am I an
>owner for
>> that channel?
>
>[Steve Kille] 
>
>The intention is that you state this explicitly.   You can choose to
>create a room and assign others as owners.   I'll add a few words

So, does that mean you can create a room in such a way that you lack full 
control over? That doesn't sound optimal, although I like explicit over 
implicit.

What happens if you omit the Owners field? Is the default a single item, being 
the bare JID of the creator?


-- 
Cheers,

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

Re: [Standards] Abolishing 'proposed' status for XEPs

[Kevin Smith]

I note that my suggestion in the MUC for this was that there were three 
outcomes from an LC, and Council will pick which. Draft, Rejected or 
Experimental, and Rejected really did mean rejected.

/K

> On 23 Apr 2018, at 19:11, Dave Cridland  wrote:
> 
> 
> 
> On 23 April 2018 at 17:59, Matthew Wild  > wrote:
> On 23 April 2018 at 16:46, Dave Cridland  > wrote:
> > -1 to removing Proposed. We only know there's a problem because a bunch of
> > XEPs are sitting in Proposed; removing Proposed wouldn't remove the problem,
> > just the fact we can see it. I'd really like a similar state during the CFE,
> > since that's quite hard to manage.
> 
> I believe the problem is completely artificial, and only exists within
> the framework that we constructed.
> 
> There is a different between "this XEP is not ready for Draft" and
> "this XEP should be rejected". The 'Rejected' state was included in
> the process as an intentional dead-end, not a holding place for XEPs
> which may come back to life (Deferred is more appropriate for that).
> 
> I think the typical negative vote from Council members is a statement
> of opinion that the XEP is not ready to be advanced. This is different
> to actively rejecting the XEP, which is something that happens in rare
> circumstances (but has happened, for one reason or another).
> 
> 
> 
> This is an argument for getting rid of Rejected, not getting rid of Proposed.
>  
> > My preferred change would be to update XEP-0001 such that anyone can fish a
> > XEP from Rejected back to Experimental (without a vote) by an update, much
> > as Deferred XEPs can be recovered.
> 
> So the only difference between Rejected and Deferred would become
> "this XEP had the misfortune of having been considered for Draft and
> receiving some negative feedback".
> 
> 
> This is an argument for getting rid of Rejected, not getting rid of Proposed.
>  
> > Rejected therefore becomes a state indicating that the XEP cannot advance in
> > its current form, instead of a terminal state.
> 
> I think this would only be valuable if we do a better job of recording
> (perhaps in the XEP), the reason why it was rejected.
> 
> 
> This is an argument for getting rid of Rejected, not getting rid of Proposed.
>  
> > There is, however, a gotcha here. A Council vote on Approval (ie, advance to
> > Draft) can have three outcomes. The vote can pass, in which case the XEP
> > moves to Draft. Someone can veto, in which case it moves to Rejected (until,
> > in this new world, someone addresses the reasons behind the rejection). But
> > it can also simply not gain sufficient votes - in which case there is
> > nothing, really, to address, per-se, but nevertheless it moves to Rejected.
> >
> > But perhaps that's OK.
> 
> In the current process, it's not, because we're not able to pull it
> back to Experimental. Which is why so many XEPs are lingering in
> Proposed.
> 
> This is an argument for getting rid of Rejected, not getting rid of Proposed.
>  
> 
> Regards,
> Matthew
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards 
> 
> Unsubscribe: standards-unsubscr...@xmpp.org 
> 
> ___
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards 
> 
> Unsubscribe: standards-unsubscr...@xmpp.org 
> 
> ___

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

Re: [Standards] Abolishing 'proposed' status for XEPs

[Dave Cridland]

On 23 April 2018 at 17:59, Matthew Wild  wrote:

> On 23 April 2018 at 16:46, Dave Cridland  wrote:
> > -1 to removing Proposed. We only know there's a problem because a bunch
> of
> > XEPs are sitting in Proposed; removing Proposed wouldn't remove the
> problem,
> > just the fact we can see it. I'd really like a similar state during the
> CFE,
> > since that's quite hard to manage.
>
> I believe the problem is completely artificial, and only exists within
> the framework that we constructed.
>
> There is a different between "this XEP is not ready for Draft" and
> "this XEP should be rejected". The 'Rejected' state was included in
> the process as an intentional dead-end, not a holding place for XEPs
> which may come back to life (Deferred is more appropriate for that).
>
> I think the typical negative vote from Council members is a statement
> of opinion that the XEP is not ready to be advanced. This is different
> to actively rejecting the XEP, which is something that happens in rare
> circumstances (but has happened, for one reason or another).
>
>

This is an argument for getting rid of Rejected, not getting rid of
Proposed.


> > My preferred change would be to update XEP-0001 such that anyone can
> fish a
> > XEP from Rejected back to Experimental (without a vote) by an update,
> much
> > as Deferred XEPs can be recovered.
>
> So the only difference between Rejected and Deferred would become
> "this XEP had the misfortune of having been considered for Draft and
> receiving some negative feedback".
>
>
This is an argument for getting rid of Rejected, not getting rid of
Proposed.


> > Rejected therefore becomes a state indicating that the XEP cannot
> advance in
> > its current form, instead of a terminal state.
>
> I think this would only be valuable if we do a better job of recording
> (perhaps in the XEP), the reason why it was rejected.
>
>
This is an argument for getting rid of Rejected, not getting rid of
Proposed.


> > There is, however, a gotcha here. A Council vote on Approval (ie,
> advance to
> > Draft) can have three outcomes. The vote can pass, in which case the XEP
> > moves to Draft. Someone can veto, in which case it moves to Rejected
> (until,
> > in this new world, someone addresses the reasons behind the rejection).
> But
> > it can also simply not gain sufficient votes - in which case there is
> > nothing, really, to address, per-se, but nevertheless it moves to
> Rejected.
> >
> > But perhaps that's OK.
>
> In the current process, it's not, because we're not able to pull it
> back to Experimental. Which is why so many XEPs are lingering in
> Proposed.
>

This is an argument for getting rid of Rejected, not getting rid of
Proposed.


>
> Regards,
> Matthew
> ___
> 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] Abolishing 'proposed' status for XEPs

[Matthew Wild]

On 23 April 2018 at 16:46, Dave Cridland  wrote:
> -1 to removing Proposed. We only know there's a problem because a bunch of
> XEPs are sitting in Proposed; removing Proposed wouldn't remove the problem,
> just the fact we can see it. I'd really like a similar state during the CFE,
> since that's quite hard to manage.

I believe the problem is completely artificial, and only exists within
the framework that we constructed.

There is a different between "this XEP is not ready for Draft" and
"this XEP should be rejected". The 'Rejected' state was included in
the process as an intentional dead-end, not a holding place for XEPs
which may come back to life (Deferred is more appropriate for that).

I think the typical negative vote from Council members is a statement
of opinion that the XEP is not ready to be advanced. This is different
to actively rejecting the XEP, which is something that happens in rare
circumstances (but has happened, for one reason or another).

> My preferred change would be to update XEP-0001 such that anyone can fish a
> XEP from Rejected back to Experimental (without a vote) by an update, much
> as Deferred XEPs can be recovered.

So the only difference between Rejected and Deferred would become
"this XEP had the misfortune of having been considered for Draft and
receiving some negative feedback".

> Rejected therefore becomes a state indicating that the XEP cannot advance in
> its current form, instead of a terminal state.

I think this would only be valuable if we do a better job of recording
(perhaps in the XEP), the reason why it was rejected.

> There is, however, a gotcha here. A Council vote on Approval (ie, advance to
> Draft) can have three outcomes. The vote can pass, in which case the XEP
> moves to Draft. Someone can veto, in which case it moves to Rejected (until,
> in this new world, someone addresses the reasons behind the rejection). But
> it can also simply not gain sufficient votes - in which case there is
> nothing, really, to address, per-se, but nevertheless it moves to Rejected.
>
> But perhaps that's OK.

In the current process, it's not, because we're not able to pull it
back to Experimental. Which is why so many XEPs are lingering in
Proposed.

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

Re: [Standards] Abolishing 'proposed' status for XEPs

[Dave Cridland]

-1 to removing Proposed. We only know there's a problem because a bunch of
XEPs are sitting in Proposed; removing Proposed wouldn't remove the
problem, just the fact we can see it. I'd really like a similar state
during the CFE, since that's quite hard to manage.

My preferred change would be to update XEP-0001 such that anyone can fish a
XEP from Rejected back to Experimental (without a vote) by an update, much
as Deferred XEPs can be recovered.

Note that a XEP can't go from Rejected -> Experimental -> Proposed -> Draft
without having the factors leading to its rejection corrected or rendered
irrelevant by time.

Rejected therefore becomes a state indicating that the XEP cannot advance
in its current form, instead of a terminal state.

There is, however, a gotcha here. A Council vote on Approval (ie, advance
to Draft) can have three outcomes. The vote can pass, in which case the XEP
moves to Draft. Someone can veto, in which case it moves to Rejected
(until, in this new world, someone addresses the reasons behind the
rejection). But it can also simply not gain sufficient votes - in which
case there is nothing, really, to address, per-se, but nevertheless it
moves to Rejected.

But perhaps that's OK.

Dave.


On 23 April 2018 at 15:09, Matthew Wild  wrote:

> We have a number of XEPs stuck in 'proposed' with an expired Last Call.
>
> I think the reality is that the council "rejected" these, or last call
> feedback is awaiting to be incorporated. By "rejected" I mean to imply
> that the council didn't want to advance the XEP yet (presumably based
> on LC feedback), but they did not want development on the XEP to
> discontinue.
>
> However XEP-0001 doesn't specify a way back to 'Experimental' from
> 'Proposed', which is why I think our documented process is not being
> followed here.
>
> I think we wither need to fix that process (by specifying Proposed ->
> Experimental), or... and this is what I think I personally prefer,
> remove the 'Proposed' status entirely (unless someone can state what
> purpose it serves).
>
> Thoughts welcome.
>
> Regards,
> Matthew
> ___
> 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] XEP-0369: MIX - About create a room/channel

[Steve Kille]

> -Original Message-
> From: Manuel Rubio 
> Sent: 23 April 2018 16:12
> To: XMPP Standards 
> Cc: Steve Kille 
> Subject: Re: [Standards] XEP-0369: MIX - About create a room/channel
> 
> Hi Steve,
> 
> thanks for your answers. About one I think was omitted, if I (hag66) create a
> channel saying the owners are "hecate" and "greymalkin", am I an owner for
> that channel?

[Steve Kille] 

The intention is that you state this explicitly.   You can choose to create a 
room and assign others as owners.   I'll add a few words


Steve



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

Re: [Standards] XEP-0369: MIX - About create a room/channel

[Manuel Rubio]

Hi Steve,

thanks for your answers. About one I think was omitted, if I (hag66) 
create a channel saying the owners are "hecate" and "greymalkin", am I 
an owner for that channel?


Thanks.
Manuel Rubio.

El 2018-04-23 15:46, Steve Kille escribió:

Manuel,


-Original Message-
From: Standards  On Behalf Of Manuel Rubio
Sent: 23 April 2018 09:30
To: standards@xmpp.org
Subject: [Standards] XEP-0369: MIX - About create a room/channel

Hello,

I was reading today the create form for the room creation. I have 
several
doubts about that. First one, is it possible to include as many owners 
as

I want
and they are supposed to be included in the channel or only are 
intended

to be

owners when they join to the channel?

[Steve Kille]

Being an Owner is actually independent of joining the channel.   It
identifies JIDs that can manage configuration of the channel.  For 
example
you might have an Admin with owner rights who does not participate in 
the

channel.





   
  
 
  urn:xmpp:mix:1
 
 
 hecate@shakespeare.example
 greymalkin@shakespeare.example
 
 
allowed
  
 
jid-mandatory-visible
  
  
 true
  
  
   


I this case hag66@shakespeare.example is adding to hecate and 
greymalkin

as
owners. Is intended "hag66" is the first owner and the others are 
owners

as

well? are they forced to be included in the channel?

[Steve Kille]

Owners do not need to be channel participants.  I'll add a note in 
3.9.1 to

make this clear




And, is it possible to add different fields? I understand (but it's 
not
clear) these fields belongs to the configuration node, is it possible 
to

add

variables from information node like Name and Description?

[Steve Kille]

Yes.  These are fields from the configuration node.   I'll update 6.5.2 
to
make this clear.To modify other nodes, such as information node, 
you

need to use the operations to modify those directly.



Thanks.
Manuel Rubio.

[Steve Kille]

Thanks for the input.   I'll address the points in the next update I 
make


Regards


Steve




___
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] Abolishing 'proposed' status for XEPs

[Kevin Smith]

On 23 Apr 2018, at 15:09, Matthew Wild  wrote:
> We have a number of XEPs stuck in 'proposed' with an expired Last Call.
> 
> I think the reality is that the council "rejected" these, or last call
> feedback is awaiting to be incorporated. By "rejected" I mean to imply
> that the council didn't want to advance the XEP yet (presumably based
> on LC feedback), but they did not want development on the XEP to
> discontinue.
> 
> However XEP-0001 doesn't specify a way back to 'Experimental' from
> 'Proposed', which is why I think our documented process is not being
> followed here.
> 
> I think we wither need to fix that process (by specifying Proposed ->
> Experimental), or... and this is what I think I personally prefer,
> remove the 'Proposed' status entirely (unless someone can state what
> purpose it serves).
> 
> Thoughts welcome.

I agree with doing something. I don’t have particularly strong feelings on 
which of these two somethings is more appropriate.

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

Re: [Standards] Abolishing 'proposed' status for XEPs

[Peter Saint-Andre]

On 4/23/18 8:09 AM, Matthew Wild wrote:
> We have a number of XEPs stuck in 'proposed' with an expired Last Call.
> 
> I think the reality is that the council "rejected" these, or last call
> feedback is awaiting to be incorporated. By "rejected" I mean to imply
> that the council didn't want to advance the XEP yet (presumably based
> on LC feedback), but they did not want development on the XEP to
> discontinue.
> 
> However XEP-0001 doesn't specify a way back to 'Experimental' from
> 'Proposed', which is why I think our documented process is not being
> followed here.
> 
> I think we wither need to fix that process (by specifying Proposed ->
> Experimental), or... and this is what I think I personally prefer,
> remove the 'Proposed' status entirely (unless someone can state what
> purpose it serves).

+1 to removing Proposed.

Peter




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

[Standards] Abolishing 'proposed' status for XEPs

[Matthew Wild]

We have a number of XEPs stuck in 'proposed' with an expired Last Call.

I think the reality is that the council "rejected" these, or last call
feedback is awaiting to be incorporated. By "rejected" I mean to imply
that the council didn't want to advance the XEP yet (presumably based
on LC feedback), but they did not want development on the XEP to
discontinue.

However XEP-0001 doesn't specify a way back to 'Experimental' from
'Proposed', which is why I think our documented process is not being
followed here.

I think we wither need to fix that process (by specifying Proposed ->
Experimental), or... and this is what I think I personally prefer,
remove the 'Proposed' status entirely (unless someone can state what
purpose it serves).

Thoughts welcome.

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

Re: [Standards] XEP-0369: MIX - About create a room/channel

[Steve Kille]

Manuel,

> -Original Message-
> From: Standards  On Behalf Of Manuel Rubio
> Sent: 23 April 2018 09:30
> To: standards@xmpp.org
> Subject: [Standards] XEP-0369: MIX - About create a room/channel
> 
> Hello,
> 
> I was reading today the create form for the room creation. I have several
> doubts about that. First one, is it possible to include as many owners as
I want
> and they are supposed to be included in the channel or only are intended
to be
> owners when they join to the channel?
[Steve Kille] 

Being an Owner is actually independent of joining the channel.   It
identifies JIDs that can manage configuration of the channel.  For example
you might have an Admin with owner rights who does not participate in the
channel.   


> 
>   id='lx09df27'
>  to='mix.shakespeare.example'
>  type='set'>
>
>   
>  
>   urn:xmpp:mix:1
>  
>  
>  hecate@shakespeare.example
>  greymalkin@shakespeare.example
>  
>  
> allowed
>   
>  
> jid-mandatory-visible
>   
>   
>  true
>   
>   
>
> 
> 
> I this case hag66@shakespeare.example is adding to hecate and greymalkin
as
> owners. Is intended "hag66" is the first owner and the others are owners
as
> well? are they forced to be included in the channel?
[Steve Kille] 

Owners do not need to be channel participants.  I'll add a note in 3.9.1 to
make this clear


> 
> And, is it possible to add different fields? I understand (but it's not
> clear) these fields belongs to the configuration node, is it possible to
add
> variables from information node like Name and Description?
[Steve Kille] 

Yes.  These are fields from the configuration node.   I'll update 6.5.2 to
make this clear.To modify other nodes, such as information node, you
need to use the operations to modify those directly.

> 
> Thanks.
> Manuel Rubio.
[Steve Kille] 

Thanks for the input.   I'll address the points in the next update I make

Regards


Steve




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

[Standards] XEP-0369: MIX - About create a room/channel

[Manuel Rubio]

Hello,

I was reading today the create form for the room creation. I have 
several doubts about that. First one, is it possible to include as many 
owners as I want and they are supposed to be included in the channel or 
only are intended to be owners when they join to the channel?



  
 

 urn:xmpp:mix:1


hecate@shakespeare.example
greymalkin@shakespeare.example


   allowed
 

   jid-mandatory-visible
 
 
true
 
 
  


I this case hag66@shakespeare.example is adding to hecate and greymalkin 
as owners. Is intended "hag66" is the first owner and the others are 
owners as well? are they forced to be included in the channel?


And, is it possible to add different fields? I understand (but it's not 
clear) these fields belongs to the configuration node, is it possible to 
add variables from information node like Name and Description?


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