[Council] final voting reminder!
stpeter at stpeter.im
Mon Oct 27 17:12:47 CDT 2008
Dave Cridland wrote:
> On Fri Oct 24 23:54:36 2008, Peter Saint-Andre wrote:
>> Dave Cridland wrote:
>> > On Fri Oct 24 22:51:57 2008, Peter Saint-Andre wrote:
>> >> Dave Cridland: XEP-0053,
>> > Hmmm - I *did* register my vote, and it's even counted on the tally.
>> > assuming this 10 days rule doesn't really mean "10 days to vote
>> yes". ;-)
>> I wanted to get clarification from you about whether version 1.4rc2
>> addressed your concerns.
> Sure, but if there's a 10-day timer on reviewing, finding any possible
> concerns, raising them, resolving them, re-reviewing, and so on, then it
> seems there is a very real risk that timer will expire. I appreciate
> that you came back quickly with some minor edits, and as it happens my
> concerns were very minor, and had the document passed through without
> further input that wouldn't have been a bad thing (except for me, anyway).
Good point. We've never enforced the 10-day timer before, so that may
have unforeseen implications.
>> > However, the changes in the current 1.4 look fine to me. But I'd
>> like to
>> > know that other folk are still okay.
>> So "in future" (as you Brits say), shall we double check with Council
>> members for every concern that is addressed? And if so will we ever
>> finish any voting, given that a completely new vote will be required for
>> each minor revision? And what modifications require a revote?
>> Wordsmithing? Typo fixes? Changing a "may" to a "MAY"? Adding a missing
>> 'id' attribute? But perhaps we need a Procedural XEP defining all this.
>> If we can ever vote it to Active.
> The purpose of the Council, as I see it - and you can correct me if you
> like - is to provide an objective and informed viewpoint of changes to
> Now the moment any concern is raised, and that member is involved with
> its resolution, the member's viewpoint isn't as objective anymore. So
> arguably, they've become the member least able to look at the new
> revision as a whole.
> So yes, I'd hope the other Council members are checking the resolution,
> just to make sure it's not introduced anything unexpected.
I'd be happy to add all Council members to the xmpp-commits list. :)
>> > And yes, I do seem to be becoming very picky about procedure, don't I?
>> I think you're a DoS sent from the IETF. :P
> Oh, you've got clause 6 for that, no member can be an effective DoS.
>> > While I'm being so picky, perhaps the right thing for the tally is
>> > actually:
>> > a) As Date, the date when the vote was officially commenced. I'd think
>> > this ought to be the first meeting for which the document is placed on
>> > the agenda, or when the new revision were submitted.
>> > b) Each new revision, post-rejection, should create a new line. So in
>> > this case, we'd have:
>> > XEP-0053 -1 . +1 +1 +1 2008/10/15
>> > XEP-0053 +1 . . . . 2008/10/22
>> > c) I suspect that we still need a 10 day timeout for those "re-votes",
>> > but rather than DNV they should default. This effectively means you've
>> > 10 days to review the changes.
> Okay, 5 days. But if you're saying there cannot be a timer restart, we
> have a different avenue for DoS, since that veto would have been ignored.
I think if someone has concerns then they need to vote -1. Then we work
to address that person's concerns, and we do so as long as needed. But I
agree that the resulting modifications need to be reviewed by the rest
of the Council. That may or may not require a restart -- it's a bit of a
judgment call, depending on how serious the changes are.
> Would it have mattered, with this case? Doubtful. But in principle, a
> minor change to you might well be a major change to me.
Right. So Council members need to pay attention. :)
> Is it a good example to use to figure out the right policy? Good enough.
> I'd hate to find an example where it mattered and have to figure things
> out then.
>> > I have to admit, I'd like to see vetos recorded.
>> More work. Is it worth it? People can look at the list archives, the
>> meeting logs, the SVN check-ins, etc., for interim discussion. We log
>> all that stuff for a reason.
> I think it's still important data to have listed at a glance, somewhere,
> if for no other reason than it provides a guage of performance next year.
But then it requires more precise versioning, separate publication of
interim versions for reference purposes, archiving of those interim
versions (right now we redirect interim versions to the main spec once
changes are approved), etc. There are process implications here that
seem not worth it to me, but perhaps that's because I'm the one doing
the work. If the XSF had lots of money and staff to handle these tasks,
I might not object so strenuously.
>> >> XEP-0206,
>> > Reading through BOSH I noticed other stuff that needs a bit of work -
>> > nothing major, just oddities.
>> > body MUST be empty - good.
>> > server SHOULD ignore - fine.
>> > server MAY send - wrong - this is not truly optional behaviour.
>> > "[...] SHOULD ignore it. Some implementation are known to send that
>> > stanza when [...]" is prefereable, to avoid the implication that
>> > the stanza is actually okay.
>> > Assuming you fix this, I'm +1, but as things stand that's a -1.
>> Great! I love -1 votes. It means that someone is paying attention.
> Ah, I only do it so I can prove I've read the stuff. ;-)
> That was horribly unclear, though - I'm referring to the paragraph at
> line 220, and in particular the parentheses at the end.
Upon receiving the <success/> element, the client MUST then ask the
connection manager to restart the stream. It does this by setting to
"true" the 'xmpp:restart' attribute (qualified by the 'urn:xmpp:xbosh'
namespace) of the BOSH <body/> element. When sending the restart
request, the client SHOULD also include the 'to' and 'xml:lang'
attributes. In addition the <body/> MUST be empty (if the client
includes an XML stanza in the body, the connection manager SHOULD ignore
it but MAY send that stanza when the stream is restarted; however there
is no guarantee that a connection manager will send the stanza so a
client cannot rely on this behavior).
We had some discussion about that on the BOSH list. Some current
implementations will accept a body in the restart request, and send it
on when stream is restarted. However, we don't want anyone to depend on
that behavior, thus the wording. I'm open to suggestions for improvement.
More information about the Council