Subject: [Simple] Presence data model - capabilities

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Mar 2005 00:55:34 -0500

The prescaps extension to pidf is based strongly on callee caps. How 
callee caps should be used is strongly determined by the matching 
algorithm in callerprefs, which in turn is based on RFC 2533. A 
consequence of that is that a preference for any value of a feature F 
will match a capability set that doesn't mention feature F. (E.g. if you 
don't mention 'duplex' as a feature, you will match those with 
preferences for either 'full' or 'half'. If you don't mention 'video', 
you will match those with a preference for either video=true or 
video=false.)

When we map callee caps to presence, we don't necessarily bring along 
the matching algorithm - no matching algorithm is specified. But 
prescaps does mention this, and recommends following the recommendations 
of callee caps - to report the status of as much as you are willing to 
have disclosed.

The presence data model doesn't mention this. Nor does it follow this in 
the examples.

I think we should decide whether we want to advocate following this 
practice or not, and then make the example adhere to the decision. I 
think this is not so easy a decision to make. On one hand it would be 
much more user friendly, and concise, to declare that in presence you 
don't have something if you don't say you have it. But doing so for 
prescaps would break the equivalence to callee caps, and the ability to 
directly derive prescaps values from the reg event package.

	Paul

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple