Re: [Standards] XEP-0115 redux

[Peter Saint-Andre]

Kevin Smith wrote:

The short version for people who don't want to read: I'll +1 the spec
we voted on last night at next council unless someone posts saying
that they agree with any of my objections. I won't turn this into
another PEP if no-one agrees.

On Jan 9, 2008 11:14 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:

OK folks, it seems that we're not quite there on XEP-0115 (Entity
Capabilities), or at least that some people (especially important people
with votes on the XMPP Council ;-) don't quite understand the logic
behind certain aspects of what we agreed to on the list.

Yeah, ok, I'm put back in my place.

Hey Kevin it's not about places, it's about moving on with our lives. :)

ISSUE #1: Do we need a new namespace?

I don't believe so (I actively believe not).

ISSUE #2: Should the 'v' attribute be REQUIRED?

Ok, I didn't join in on the list on this because I didn't want to keep
repeating myself after saying it at council in August. Anyway, I'll go
with RECOMMENDED for the sake of compromise (it's compromise we build

here, rather than consensus, I think).

I suppose consensus involves compromise...

To repeat my motivations for
wanting ver in there: 1) The users want it, and we serve the users
(the outcry was significant when we went from an iq:version flood to

versions from caps clients in Psi),

Aha, that's good to know.

2) knowing the remote entity
version does, in the future, allow us to hard-code backwards
compatability (no, it's not a situation I'd like to see, but if we
lose versioning now, we never have the option. Anyway, I'll drop my
objections at next council as long as I'm the only one here who feels
this way.

Although I have no deep objections to including the version, I can understand why some people might object (and they did on the list), for example beacuse of security concerns (I don't share those concerns, but that's immaterial).

ISSUE #3: Which hashing algorithms?

My preference is a mandatory MD5, because it seems daft going with
SHA1 (a third longer hashes) if it doesn't buy us anything over MD5.
List consensus seems to be SHA1 though, so I'm not going to block on
that as long as the way remains clear on list.

Peter

--
Peter Saint-Andre
https://stpeter.im/

If we were designing this from scratch I would not particularly care, but version 1.4 effectively says to support SHA-1 and people have been coding to that since July or August. Now if we change it because the hashes are a third longer in SHA-1, I think developers won't be very happy. And I like happy developers. :)

smime.p7s
Description: S/MIME Cryptographic Signature