[Standards] Entity Capabilities Woes

Peter Saint-Andre stpeter at jabber.org
Thu Mar 15 21:09:51 UTC 2007


Daniel Noll wrote:
> On Friday 16 March 2007 06:19, Peter Saint-Andre wrote:
>> Remko Tronçon wrote:
>>>> Would be the same for most cases - but from protocol point of view : it
>>>> need not necessarily be the same.
>>>> Hence, we cache it as a tuple of all three and dont assume that it is
>>>> same across versions.
>>> That's what we do as well. But on the other hand, if you can assume
>>> it, you can cache it by a mapping from disco node
>>> (http://psi-im.org/caps#0.11, http://psi-im.org/caps#cs) to features,
>>> making it even easier to implement (and avoiding even more disco
>>> requests).
>> Well as my illustrious co-author said, the intent was that ext is stable
>> across application versions. If we make that a MUST in the spec then we
>> can save more packets. Seems like a good idea to me.
> 
> I can sense this causing a headache further down the track.  Some client will 
> put in an "ft" feature for file transfer on version 1.0, and then in version 
> 2.0 they will add Jingle support.  Clients who happen to query version 2.0 
> first will cache that "ft" means Jingle FT, and then interesting things will 
> happen when they encounter a version 1.0 client.

That's a different feature, so the client author should change the name 
of the extension.

> It seems like it would be easier for everyone (except disk space, which is 
> cheap anyway) 

Not for web clients or mobile devices. :)

> if it were assumed that ext is completely free of semantics.

All we're saying is that node#ext is stable. I don't know if I would 
call that semantics.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070315/baa591bd/attachment.bin>


More information about the Standards mailing list