[Council] Votes from 2008-10-15
stpeter at stpeter.im
Wed Oct 22 09:05:56 CDT 2008
Dave Cridland wrote:
> 2) Can we actually vote? It says <approver>Board</approver>, which seems
> to suggest we can't. (Well, we can, we just can't approve it based on
> such a vote).
Thank you for your close attention to detail. :P
The Board was the entity that originally approved the formation of the
XMPP Registrar function. I think that a change to the Registrar's
namespace issuance process is more within the purview of the Council,
and in general we prefer to ask the Council for its advice and input on
technical matters such as this. However, we could still ask the Board
for its approval, too (which in technical matters it will typically just
rubber-stamp). If I recall correctly, that is how we've proceeded with
previous changes to XEP-0001 and XEP-0053 (ask both the Board and the
Council to approve).
> I note that the XMPP Registrar doesn't actually make the registration
> while the document is in Experimental state, and I'm mildly concerned
> that this can - in theory - lead to a state where two XEPs in
> Experimental end up with the same namespace, which is a bit silly.
Correct, the namespaces are minted when the XEP is Experimental but not
registered until the XEP is Draft. Registering every namespace might
clutter up the registry with namespaces that are not approved and never
will be, and that strikes me as a bad idea (in particular it might cause
confusion regarding which namespaces are approved and which are not).
> In practise, I assume that we do actually track what namespaces are used
> by Experimental XEPs, so it seems sensible for the XMPP Registrar to
> make a note of these in the same way as any other used namespace.
All namespaces are checked for uniqueness before they are minted, and
that check includes XEPs in all states, not just Draft or Final. Would
you prefer to make that explicit?
> Also, the use of the phrase "[...], or if significant new features have
> been added" I find somewhat misleading - it suggests that there's a case
> where the "new" protocol is entirely backwards compatible with the "old"
> - ie, there is no loss of interoperability - but we still want to change
> the namespace to break said interoperability. I'm not clear what case
> this is.
I agree to strike that clause.
> So, if my vote meant anything, I'd vote -1. But we're very close. :-)
Your feedback is appreciated.
> 3) I don't know of any reason not to press on with those.
I assume that the Council Chair will add those to future agendas.
> 4) There's a significant amount of small cleanup work here. It'd be
> useful to have these seperated out.
What format would you find useful? A more detailed changelog?
> However, I've gone through it all and I'll vote +1 to both the changed
> XEP-0124 and bosh-script.
> 5) No idea, so I'll go through the mailing list as see if I can get a
> handle on the change.
> 6) +1
Jack raised an issue about backwards-compatibility regarding the
<error/> and <accuracy/> elements, and I sent a "poll" about this to the
jdev@ and standards@ lists. One solution would be to say that
implementations shall support both <error/> (= offset in arc minutes)
and <accuracy/> (= offset in meters) for some period of time, i.e., to
not immediately deprecate <error/>. But first we need to find out if any
implementations support <error/> (I have my doubts).
> 7) I still think USer Mood is very silly, but ours not to reason why. +1.
Well, your mood is always grumpy so I can see why you'd think the idea
of publishing mood changes is silly. ;-)
> 8) I think this is approaching silliness, too, but +1.
If you ask me, activity is even more risible than mood. But I try not to
let me personal usage and biases interfere with publishing specs that
some parts of the community deem useful (unless the protocol would cause
> 9/10) +1 to Last Call, however I'd like us to watch these carefully to
> ensure we are actually getting feedback.
I think XEP-0224 is relatively harmless. But I would like to get some
more significant feedback on the denial of service considerations since
that is referenced from rfc3920bis. I think I'll ask for feedback about
that on the operators@ list in addition to standards@ and jdev at .
> 11/12) In both cases I'm not convinced the motivation matches the design
> at all. I've a very different view of how chaining might work - this
> design seems to fit aggregation better than chaining - and I'm not
> convinced that PubSub and Queueing fit naturally into the same model.
> I think I need, in both cases, to have a chat with the authors to get a
> better handle on what exactly is required.
Fine with me. :)
More information about the Council