Goals:
  . as much flexibility as possible for the publisher
 
  . require little from the watcher (e.g., may not want to require caller
    preferences; work with dumb devices like black phones)

  . work for SIP and non-SIP URIs

  . work for integrated devices combining watching and communicating, and
for devices that use external helper applications for communications

A tuple *advertises* certain properties about the presentity.  In
particular, a single contact-endowed tuple advertises one means of
communicating with an instance of the presentity.  A third-party, such
as a SIP proxy, may resolve this address into multiple different
endpoints, but this is invisible to the caller.

A contact-less tuple describes properties the presentity that can't be
represented by URIs.  There are two sub-cases:

- Communications that cannot be represented by URI, such as
  face-to-face or postal communications.

- Non-communication properties of the presentity, such as the
  location, activity, mood, state of inebriation, etc.

There is no need for an explicit face-to-face indication; a 'note'
element (or a class indication) appears to be sufficient.

A CLOSED tuple that was never announced as open to a watcher is useful
to find the status of addresses that the watcher may have learned
through non-subscription means (such as address book).

Rules for tuples (from least to most controversial):

(1) A presentity can always have multiple tuples with distinct URI schemes
(e.g., h323, tel, mailto, http). There is no other choice since there is no
common resolution protocol between them.

(2) A presentity may have multiple tuples with the same contact URI if
that URI possesses the properties listed under both of them.  This does
not necessarily imply the ability of the watcher to choose the specific
instance that posseses some subset of these properties. It simply allows
the watcher to determine that a URI has a set of properties and that
using it for something else is not likely to be successful.

Example:
  uri:a
    'has audio'
    'speaks French'
  uri:a
    'has video and IM'
    'speaks English'

This indicates that trying uri:a when only speaking Polish is not likely
to be successful.

It is possible that the same URI has tuples that are open and that are
closed.  The UI may not even show the URI itself, so this may or may not
be confusing.  In any event, a watcher simply chooses the open URIs and
ignores the closed ones, disregarding that some may have the same name.

Capabilities describe:
  - *selection* of endpoints (devices, services, ...) sharing a common
    URI
  - *description* of devices for choosing the appropriate one
    or for deciding that no appropriate communication is possible.

Selection requires one of three properties:

(1) Each tuple has a unique URI.

(2) Tuples with the same URI map to one communication service and just
describe different aspects of the service. (For example, 

   uri:a
     lang=english
   uri:a
     lang=french

If 'a' reaches a bilingual speaker speaks both English and French, there
is no need to differentiate between the two contact URIs in the tuples
and thus it does not matter that they are the same.

(3) If multiple tuples have identical contact URIs that described
communication endpoints with different capabilities that the watcher
wants to address individually, there is an algorithmic way to translate
the properties in the tuple to a protocol request.  An example is the
capabilities description that is mechanically translated, without human
intervention, into a set of caller preferences. 

Note: use of caller preferences does not require any additional
capabilities from the watcher, as long as the watcher is willing to
honor 'header' URI component that translate into caller preference
header fields.

Knowledge of contact URIs (through presence documents or otherwise) does
not convey privileges to reach the user.  The one and only role of
knowledge of information associated with tuples is to guide the watcher
from initiating inappropriate or likely-to-fail communication. It is the
responsibility of the presentity to ensure that calls do not reach it at
inappropriate times or places.


Links between tuples.