Hi all,
The approach presented in Data Model for Presence (http://www.ietf.org/internet-drafts/draft-rosenberg-simple-presence-data-model-00.txt) has been in principle approved in SIMPLE WG, but there are still some open issues on details. One of them concerns the scope of XCAP application usage for PIDF manipulation (http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt). The Data Model draft has the following text in Chapter 10:
One of the source of confusion around the XCAP manipulation of
PIDF [17] is that it was unclear as to why one would use it as
opposed to PUBLISH. The presence data model presented here sheds
some light on that. PUBLISH is appropriate for communicating
information about services and devices. PUBLISH is designed for
the model where there can be more than one such source (as there
is for devices and servcies), and where such state is soft-state
(as it should be for devices and services). However, presentity
state is not clearly soft-state, and the model here clearly
indicates that each presence document can have a single presentity
element. Thus, it might make sense to change the
pidf-manipulation spec to only allow setting of presentity tuples.
Now, that doesnt forbid a source from trying to PUBLISH presentity
information, but there is clearly a need for a hard-state approach
for setting presentity information.
The concrete issue here is whether XCAP PIDF manipulation should be restricted to setting only presentity tuple, i.e. not allow the setting of service tuples or device information.
My opinion is that we should not make this kind of restriction.
There is at least one use case where "hard state" service tuples make a lot of sense, and that is service tuples for "persistent" services such as e-mail, SMS, MMS or voicemail. These communication means are available for the sender even if the recipient is not on-line wrt. that service, since there is a network-based "inbox" taking care of them. XCAP PIDF manipulation is a better way to describe this kind "off-line" state for such services rather than SIP PUBLISH. (BTW, I believe we should define some new status attribute to this kind of services to clearly indicate the difference between "MMS available but no device on-line" vs. "MMS available with a device on-line" etc. Or probably the standardization fora responsible for e.g. MMS can do that.)
What might be a useful specification is to say that in a typical scenario information derived from SIP PUBLISH takes presedence over the information derived from XCAP. But that is already in the territory of specifying the composer policy, which I think is a separate effort from the data model of XCAP PIDF manipulation drafts.
So my proposal is basically to keep the XCAP PIDF manipulation draft as it is at the moment, and not make any restricting statements about its use in the Data Model either. Are there other opinions on this topic?
Regards,
Markus
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple