[Council] Votes from 2008-10-15

Peter Saint-Andre stpeter at stpeter.im
Wed Oct 22 10:20:57 CDT 2008

Dave Cridland wrote:
> On Wed Oct 22 15:05:56 2008, Peter Saint-Andre wrote:
>> > 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).
> Well, I think no more so than the clutter of Experimental vs Draft XEPs,
> really. I'm not saying "show them by default in registry views".

Currently there is only one registry view and we don't track the
"status" of registry items as we track the status of specifications.

>> > 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?
> Documenting the existing practise always seems like a good idea.


[6] XEP-0080

>> 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).
> Not only whether they support it, but whether they support it
> intentionally interoperably and rely upon it. I suspect we're early
> enough to make this change, and any applications which actually use it
> are quite likely talking to other instances of themselves, or form some
> similarly homogenous network.

Well, let's see what the poll results show before jumping to
conclusions. No responses yet, so I'll need to start pinging people
individually, methinks.

>> > 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. ;-)
> <offended/> ;-)
> Actually, it's largely down to the bizarre, and sometimes worrying,
> choices of iconography in Gajim. I'm sure that "Aroused" uses an icon
> intended to depict "Unexpected Body Cavity Search", and most of them
> appear to depict various stages of "Constipated".

I have no idea what the iconography suggests, because I'm more of a
textual person myself (and I don't use Gajim).

>> > 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
>> positive harm).
> In a lot of cases, I can see good uses for the Activity, although it'd
> be more use if PEP Activity states were tied into user defined rich
> presence states, and made available through a simple drop-down in the
> client. Knowing that someone's present, but eating, gives me useful cues
> to response time, etc.

Talk to the developers of your favorite client, or submit a patch.
That's what I always do (the former, not the latter). :)

> As well as satisfying my noseyness.

Always critically important.

So out of this little thread I take away the need for some edits to
XEP-0053; I'll work those in Real Soon Now [tm].


Peter Saint-Andre

More information about the Council mailing list