Subject: [Simple] comments on draft-isomaki-simple-xcap-publish-usage

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Nov 2003 11:06:23 -0500

I have a few comments on:

http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-publish-usage-00.txt

I think this is a good draft, and is the appropriate way to solve this 
problem.

My main comment is that I think we need to be very clear on the 
difference between this mechanism and SIP PUBLISH. I know we went 
through a lot of this on the list some time back. In particular, one 
could presumably use PUBLISH with an infinitely long Expires header 
field, and achieve a near "hard state" publication. I think the real 
difference is that this is provisioned data that describes the 
presentity independent of any particular device, for which we require 
any possible device, and even web pages and provisioning systems, to 
manipulate. PUBLISH is really focused on allowing a particular PUA to 
publish its view of the presentity, separate from other views 
published by other PUAs. As such, manipulating presence hard state 
from many different sources using PUBLISH is not easy, as the Etags 
would need to be shared. There is no obvious mechanism for that. Also, 
there will be a clear need to do a pure fetch of the hard state 
presence data, a feature we don't have with PUBLISH. I think the draft 
should clearly enumerate these problems, and provide guidance on when 
to use this mechanism, vs. PUBLISH.

Regarding the open issue:

>  Publishing of external content: how to publish external content
>    (e.g., an icon) referenced from PIDF in case of the XCAP based
>    publishing? Is the content transported separately from the PIDF
>    formatted document so that the PIDF includes only a reference to the
>    separately transported content and the compositor is capable for
>    linking the information together? This might require that the
>    compositor is able to change the content of the reference.

This is more of a pidf question, I think. The current leaning with 
PIDF would be to include such icons by reference. The document stored 
in the xcap server would include such a reference. That reference 
would presumably be an HTTP URI that can dreference content on the 
same server. The user would need to have a directory where they are 
permitted to upload content.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: [email-masked]
Date: Wed, 12 Nov 2003 04:49:13 +0200

Hi,

Thanks for the comments. See below:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 10 November, 2003 18:06
> To: Simple WG
> Subject: [Simple] comments on draft-isomaki-simple-xcap-publish-usage
> 
> 

I think this is a good description on the benefits of XCAP presence publishing application usage compared to SIP PUBLISH. Aki also provided some consideration why SIP PUBLISH with infinite expiration might not work. I agree that all this should be added to the next revision of the draft.

> permitted to upload content.

I agree that the best way would be to upload the external content separately using HTTP PUT and insert the URI to PIDF. In some cases the PA might want to send such information also within the NOTIFY, in which case the PA would need to fetch the data addressed by the HTTP URI, insert it as a separate MIME part and replace the HTTP URI in PIDF by a corresponding cid URI. 

Can this kind of behaviour be seen purely as an implementation issue, or is there need to write something about it somewhere? 

> -Jonathan R.

Markus