[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 <stpeter at stpeter.im> 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.

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. :)

Peter

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080110/a9cb1c0f/attachment-0001.bin