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: Aki Niemi <[email-masked]>
Date: Wed, 12 Nov 2003 02:53:52 +0200

Hi,

Inline.

ext Jonathan Rosenberg wrote:

> I think this is a good draft, and is the appropriate way to solve
> this problem.
> 
>  field, and achieve a near "hard state" publication. 

This doesn't necessarily work. In PUBLISH, the expiration is related to 
the composer's desire to clear up dead publications vs. its desire to 
throttle publication refreshes. It's just like how a registrar manages 
address bindings - the published state might be valid forever, but needs 
periodic refreshes. In practice, the ESC can't know whether the EPAs 
intention is to hog resources, or publish hard state.

> I think the real
>  manipulate. PUBLISH is really focused on allowing a particular PUA
> to publish its view of the presentity, separate from other views
> would need to be shared. There is no obvious mechanism for that.

Yes, this is an intentional limitation of PUBLISH. There is no way to 
query the full "raw" set of publications and the etags associated with them.

> 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 agree. it might also be a good idea to include a bit more about this 
in the PUBLISH draft.

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

This would work. I think the tricky part is really inline content, and 
using CIDs (assuming that's a valid option for including non-XML 
information in PIDF).

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Wed, 12 Nov 2003 02:53:52 +0200

Hi,

Inline.

Cheers,
Aki

---

From: Pekka Pessi <[email-masked]>
Date: Fri, 14 Nov 2003 22:07:03 +0200

Hello all,

	Just another comment regarding XCAP and Markus' and Eva's draft,
	raised by Jari Urpalainen.

	CPIM-PIDF is well-formed XML document. It can be extended just
	by giving a name space URI of you extension. No schema required.

	However, XCAP requires that the XML document it handles have
	a schema and that all the documents are valid.   I guess the
	intention is that all the XCAP data has either a DTD or an XML
	schema.

	Now the question is, do we want to limit the permanently
	published presence documents to a particular schema? Or is it
	possible to define publication-AU that has multiple schema? In
	any case, it seems to defeat the only good side of CPIM-PIDF...

	BR,
					Pekka

---

From: Pekka Pessi <[email-masked]>
Date: Fri, 14 Nov 2003 22:07:03 +0200

Hello all,

	BR,
					Pekka