Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt

From: Jeroen Van Bemmel <[email-masked]>
Date: Fri, 21 Jul 2006 09:59:48 +0200

Authors,

A question or comment: why use pidf-full instead of simply pidf for initial / full state publications?

I don't see a benefit, only drawbacks (duplicate definition,risk that UAS does not support it)

Why not use pidf, and have the server respond with accepted: pidf-diff if supported?

Regards,

Jeroen

-----Oorspronkelijk bericht -----
Van: [email-masked]
Aan: [email-masked]
CC: [email-masked]
Verzonden: 21-7-06 00:50
Onderwerp: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: Publication of Partial Presence Information
	Author(s)	: M. Lonnfors, et al.
	Filename	: draft-ietf-simple-partial-publish-05.txt
	Pages		: 16
	Date		: 2006-7-20
	
The Session Initiation Protocol (SIP) Extension for Event State
Publication describes a mechanism with which a presence user agent is
able to publish presence information to a presence agent.  Using the
Presence Information Data Format (PIDF), each presence publication
contains full state, regardless of how much of that information has
actually changed since the previous update.  As a consequence,
updating a sizeable presence document with small changes bear a
considerable overhead and is therefore inefficient.  Especially with
low bandwidth and high latency links, this can constitue a
considerable burden to the system.  This memo defines a solution that
aids in reducing the impact of those constraints and increases
transport efficiency by introducing a mechanism that allows for
publication of partial presence information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-publish-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-partial-publish-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-partial-publish-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: Aki Niemi <[email-masked]>
Date: Fri, 21 Jul 2006 13:12:08 +0300

> initial / full state publications?

Good question. Originally it was simply so that publish and notify sides
were aligned in their use of pidf-diff. And in the notifications, using
pidf-full is needed because of versioning support (allowing the
recipient to know against which state to patch the incoming diff state).
Also there, the SUBSCRIBE would already carry pidf-diff as allowed
content type, since it's a "pull".

But we actually dropped the version attribute from partial-publish a
while back because PUBLISH already takes care of versioning (and this is
mentioned in the draft).

However, we never went back to change principle flow.

> I don't see a benefit, only drawbacks (duplicate definition,risk that

I think I agree. In fact, starting off with pidf, and in case Accept
coming back from the server lists pidf-diff, switching to partial has
another important benefit.

In case the server gets upgraded at some point, the client needs to find
out it can start using patches. In the current flow, this would require
a pidf-full publication and an error response *every time* the client
starts its presence engine, all the way up until the point that the
server adds support. This may be forever, too, although I strongly hope
it won't be. :) 

> Why not use pidf, and have the server respond with accepted: pidf-diff

I think this is a reasonable thing to do, and I'd be willing to make the
change. Although not a huge change in principle (basically only the
initial publication is affected, and there, only the content type), in
practice there are a few places in the text that would need to change.

Cheers,
Aki

-- 
Aki Niemi
Nokia Research Center

---

From: Aki Niemi <[email-masked]>
Date: Fri, 21 Jul 2006 13:25:32 +0300

> practice there are a few places in the text that would need to change.

...except of course that, as Jari just pointed out, Accept is marked as
'-' meaning not applicable in RFC 3903, as well as RFC 3265. Which kind
of makes sense, in a weird way, as normally you really want to put
Accept in a request anyway. That's how it is in HTTP.

But of course, we could define Accpet's applicability to PUBLISH 2xx in
partial-publish.

Cheers,
Aki

P.S. I had a feeling there was some "real" reason for not doing it like
Jeroen suggested, which arguably is a better way. ;)

-- 
Aki Niemi
Nokia Research Center

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 21 Jul 2006 12:47:13 +0200

This draft has passed WGLC and was only revised due to chair request 
for fixing some NITs.

The fix below is a significant one and will require a WGLC to be issued 
again. Do you see a flaw in the current mechanism that requires fixing 
or is this proposal just a "looks better" thing?

one comment inline...

> server adds support. This may be forever, too, although I strongly hope

This sounds like a flaw to me and an interoperability issue. Can you 
summarise the changes that need to be made, in detail?

Thanks,
Hisham

---

From: Aki Niemi <[email-masked]>
Date: Fri, 21 Jul 2006 14:43:14 +0300

> summarise the changes that need to be made, in detail?

Well, I wouldn't say it's a flaw, really, or if it is then I'm not sure
we can address it in partial-publish. The underlying issue is that
Accept in 2xx is not allowed in RFC3903. This means that using Accept
doesn't actually work. 

Perhaps it's best if we just leave it alone.

Regarding the interop, this is the same issue as with any extension we
make to SIP. If a domain doesn't support the foobar event package, then
there is no mechanism apart from OPTIONS to tell you, a priori, that the
SUBSCRIBE is going to fail. You just have to use trial-and-error, which
is how it currently works for partial-publish.

Cheers,
Aki

-- 
Aki Niemi
Nokia Research Center