Subject: [Simple] Internet-Draft on hard state presence publishing

From: [email-masked]
Date: Thu, 9 Oct 2003 18:11:22 +0300

Hi all,

The work on SIP PUBLISH for presence publication seems to be concluded from SIMPLE WG point of view as the draft has been moved to SIP WG. SIP PUBLISH allows PUA to publish "soft state" type of presence information to the composer. However, publishing "hard state" information has been deliberately left out of the scope of that particular mechanism:

---

   PUBLISH requests create soft state in the ESC. This state has a
   defined lifetime and will expire after a negotiated amount of time,
   requiring the publication to be refreshed by subsequent PUBLISH
   requests. Local policy at the compositor may in turn define hard
   state for a particular event package. That is, the steady-state of
   this event package in the absence of, or in addition to, soft state
   provided through the PUBLISH mechanism. Setting this hard state or
   configuring the composer policy is out of the scope of this
   specification.

---

During the discussions related to presence publishing it was concluded that also it would be good to have a solution for "hard state" publishing. In the July IETF meeting the concensus seemed to be that an XCAP application usage would be the correct and simple solution. 

Myself and Eva Leppänen have put together an initial draft to address this issue. You can find it here:
http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-publish-usage-00.txt

The main idea is to use XCAP as the tool to manipulate the data, and the data itself is in PIDF format exactly the same way as it would be if published with SIP. The rules how a composer treats this data related to data uploaded with SIP PUBLISH is outside the scope of the draft. (The solution is specific to presence event, but using XCAP for publishing hard state for any other event is certainly possible too, but defining a generic specification for that did not seem to bring any additional value.)

There is one major open issue that should be addressed in our opinion. We would like to be able to publish also external content, e.g. the content referred by <icon> and <homepage> elements. We could include this in the draft by allowing the client to upload a file with HTTP/XCAP and reference to them from the PIDF document. Some text should be added how the composer is expected to treat this file, i.e. it should also be able to change it to become INLINE content in NOTIFY, or place it under a URI from which the watcher is able to fetch it (and change the URI in PIDF accordingly), if the original URI is not accessible. We would like to hear if people think that this problem should be in the scope of the draft too, or whether you think this requires text in the standards at all.

In general we would like to get comments by the next IETF meeting and if the draft seems OK, adopt is as a WG item.

Regards,
	Markus 

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