Composing and Grouping Tuples into Different Views Presentities may want to expose different levels of detail for themselves, ranging from having one tuple to exporting details for each and every communications device. A composing function should be able to systematically and automatically merge multiple tuples in sensible combinations. (Naturally, more complicated combinations may require human intervention or more elaborate rules than the ones presented here.) We start from elementary tuples, i.e., tuples that cannot be further decomposed into multiple SIP or other addresses. (It may still be possible to designate specific capability combinations as a separate SIP URI that maps to the same UA, with the same network address. For example, sip:alice+audio@phone42.example.com may address the audio component of the phone and only enable audio, while sip:alice@phone42.example.com might address all of the device's capabilities. In that case, each of these addresses is represented by an elementary tuple.) Typically, elementary tuples are published by devices themselves. Multiple elementary tuples can be combined into one composed tuple. Composed tuples can be further composed. In this composition model, tuples can be thought of as rows in a relational database. Each row represents an elementary or composed tuple. There are two views of what a column entry represents: (1) It may represent simply the fact that one or more tuples had one of the properties or capabilities. For example, in this model, if we have a column representing the set of media supported, a video-only tuple and an audio-only tuple would merge into an 'audio,video' tuple. This does not indicate that the tuple represents a contact that can support both media. Two contacts that each support both audio and video would yield the same result, even though the capabilities of the contacts are quite different. If one instead defines each column to be binary, e.g., one column describes the boolean 'supports video', another 'supports audio', the composition of the two mono-media tuples would yield 'true,false' for each column. This combination indicates to the watcher that some components of the composed row have the capability, others do not. Clearly, a watcher cannot assume that selecting any random combination of column entries (e.g., via caller preferences) will reach a valid end point. Currently, the RPID and PIDF definitions do not support such sets. Thus, this use case argues for possibly reconsidering this restriction. The union model is similar to the centroid model proposed for whois++ (RFC 1835). (2) It represents the property possessed by all tuples that were merged, i.e. the intersection of the values in the rows that contributed to the merged tuple. If there is no common value, the column entry would be empty or undefined. Composition rules can be defined for each presence element. For the element, with an intersection rule, device-specific contacts would be removed, rendering the merged tuple useless. Thus, the merging entity would need to create a dynamic tuple that represents just the merged tuples or, alternatively, each tuple would (also) have to use the presentity's AOR as a Contact. Only tuples with the same AOR could then be merged. This suggests that device-oriented tuples make visible both the AOR that they are reachable under and the device-specific contact (e.g., a GRUU or a network-interface direct contact address.) Here, we define AOR as either being a SIP address-of-record or any URI with another scheme, such as pres:, h323: or im:. (Other URIs do not allow the resolution of an 'umbrella' URI into more specialized URIs.) For example, suppose we have two devices, a PC at alice@pc42.example.com (and maybe as alice-56870@example.com) and a phone, operated by a different company and natively addressed as alice@phone17.example.net (and alice-3456@example.com). These two device elementary tuples can be merged into a single tuple if there is a common AOR, such as alice@example.com. *** Grouping (or pivoting) Grouping is a special kind of compositing, where one parameter is selected as the grouping indicator. Compositors and watchers can perform grouping. Rows are sorted by that parameter values and all rows with an equal parameter value for the grouping column are merged, as above. For example, if we have the rows media mobility placetype privacy activity --------------------------------------------- a,v fixed home private away a mobile NULL public meeting t mobile NULL private meeting (Here, a=audio, v=video, t=text) we can group them by media as media mobility placetype privacy activity -------------------------------------------------------- a fix,mob home private away,meeting v fixed home private,public away t mobile NULL private meeting The composition rule 'union' was used for all attributes. Also, all rows were assumed to have the same AOR, as otherwise composition would not be possible. Here, we applied another heuristic, namely to split columns with sets containing more than one element into multiple rows, so that the intermediate step was media mobility placetype privacy activity --------------------------------------------- a fixed home private away v fixed home private away a mobile NULL public meeting t mobile NULL private meeting Grouping also allows the composer or watcher to compress the presence information into the minimal number of rows, by grouping on the AOR, so that each tuple has a unique AOR.