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

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 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.
> 

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.

> 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.
> 

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.
> 
> -- 
> 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
> 

Markus

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Nov 2003 03:57:44 -0500

inline.

[email-masked] wrote:

>> -----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 draft, and is the appropriate way to solve
>> this problem.
>> 
>>  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.
>> 
> 
> 
> 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.

Right. I agree with Aki's discussion on the infinite expiration doesnt 
work. My main point is that the text needs to discuss these things, 
NOT that I was proposing PUBLISH!

>>>  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.
>> 
> 
> 
> 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?

I think if you want NOTIFY's to contain PIDF documents with references 
to CID URIs in the same NOTIFY, you need to write that up.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Nov 2003 03:57:44 -0500

inline.

-Jonathan R.