[Members] the "Proposed" state in XEP-0001

Peter Saint-Andre stpeter at stpeter.im
Thu Mar 10 16:27:37 CST 2011

On 3/10/11 3:27 PM, Kurt Zeilenga wrote:
> On Mar 10, 2011, at 2:19 PM, Peter Saint-Andre wrote:
>> On 3/10/11 3:18 PM, Kurt Zeilenga wrote:
>>> On Mar 10, 2011, at 2:13 PM, Peter Saint-Andre wrote:
>>>> On 3/10/11 3:12 PM, Kurt Zeilenga wrote:
>>>>> On Mar 10, 2011, at 1:29 PM, Peter Saint-Andre wrote:
>>>>>> I've effectively stopped using the "Proposed" state defined
>>>>>> in XEP-0001 (too many specs went into Proposed during Last
>>>>>> Call but had to be moved back to Experimental because the
>>>>>> authors needed to revise the XEP before the Council would
>>>>>> approve it, and sometimes they were in the Proposed state
>>>>>> for a long time). I wonder if we want to get rid of it
>>>>>> entirely...
>>>>> +1
>>>>> What about Reject?  The state digram shows the only way to
>>>>> Reject is via Proposed.
>>>> The Council hasn't moved anything to Rejected since 2002, and
>>>> then only at a single meeting.
>>> I was more recently advised not to request progression to Draft
>>> until I was sure it would be approved else the XEP might get
>>> moved to Rejected and I'd have submit a new Proto-XEP...
>>> If a XEP is not ready for Draft, I rather the council say
>>> "address X and Y at Experimental and then resubmit"...
>> Well, that happens nowadays because the Council needs to approve 
>> issuance of a Last Call. That has enabled us to avoid Rejected.
> so far.
> My point is that it clearly possible that a Last Call would get
> issued and then the Council learns something during that call that
> leads it to deny the request for progression.  If this were to
> happen, I think it would be generally for the document remain in the
> Experimental state (so the issues raised during Last Call can be
> addressed) then automatically be moved into a dead-end state
> (requiring the authors to submit a whole new XEP with largely the
> same content).

Right, and that's what happens now.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/members/attachments/20110310/01fa27e6/attachment.bin>

More information about the Members mailing list