RE: [Simple] Updated RPID

["Dag Ekengren" <dag.ekengren at hotsip.com>]

Henning Schulzrinne wrote:

>This is different. It simply includes the data with the source tuple
>that generated it.

I think this approach may make things less expressive. If I provide
information about the person in the service tuple, how can I specify
that this information is really about the person? How can I
differentiate that information from information about the service?

Let's say I would like to have a text note that describes the person and
another text note that describes the service. It feels natural to put
this information in two different elements because it is describing to
different entities.

I think it will be confusing to put the activity "busy" on a service
tuple if I mean that the person is "busy". One could say that the
activity element only applies to the person, and in the same way for
each element define if it applies to the person or to the service. But I
think that is more confusing than including the attribute in the element
to which it applies.


>This is no more complicated than the alternative
>approach, and in the absence of a defined composition operation, almost
>unavoidable. In practice, with all existing and plausible near-term
>composition operations (which will be effectively some form of union or
>concatenation), this will occur whether we allow for this or not. 

If the data is separated so that the presence document clearly describes
to which entities the data applies, presence composition will be easier.

If the service tuple actually describes the service, then composition of
the service tuples can be done quite easily. With the usage of GRUU:s
the service tuples will have different contact uri:s and composition is
a matter of including all the tuples.

As for the person tuple, I think a simple policy like "the latest
timestamp wins" will get you very far at least for information
explicitly published by the user. If the user explicitly publishes
information, he probably wants that information to be visible to
watchers.

Automated publications are more complicated. For example, a calendar
application that publishes <person> elements should not override the
information the user explicitly has set. To solve this, some kind of
source information may be necessary. The watcher should be able to see
both the information published as well as the information published by
the calendar. One shouldn't override the other. But that doesn't mean
that they both can't publish person tuples. One could for example let
the composed person tuple contain two text notes, one from the calendar
and one from user.

/Dag




_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple