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

From: Aki Niemi <[email-masked]>
Date: Fri, 28 Jul 2006 10:31:06 +0300

On pe, 2006-07-21 at 20:01 +0200, ext Jeroen van Bemmel wrote:
> Aki,
> 
> I think you should drop pidf-full altogether (remove it completely), and
> only use pidf and pidf-diff. For versioning of notifications you can simply
> use the CSeq number (initial NOTIFY MUST be pidf)

This is a pretty substantial change. It affects not only partial-publish
but -format and -notify as well. And is more of a complete rewrite.

I'm wondering if this is all that much better, or just different. You
still require a new, separate content type. The 'version' attribute
still needs to be there in pidf-diff (to account for partial traversing
CPP gateways) and so on.

Is there something obvious that makes the current mechanism broken? If
not, can you live with what's there now?

> Even if Allow is not allowed in 2xx to PUBLISH, it is still better to use
> pidf in the initial PUBLISH. If a subsequent pidf-diff fails because of UAS
> not supporting, the wasted effort is less. 

I think you mean Accept, but how much 'better' is it really. You still
don't save a round trip, since in your proposal, the first partial
update would still fail, requiring a resend.

Cheers,
Aki

-- 
Aki Niemi
Nokia Research Center

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 30 Jul 2006 18:49:38 +0200

Hi Aki,

see inline

Regards,

Jeroen

> not, can you live with what's there now?

It is mostly that pidf-full seems to add unnecessary overhead and 
complexity. Given that the purpose of this draft is reduction of message 
size, it would be odd to introduce inefficiencies, in particular if the view 
now is that the original reason for introducing pidf-full (versioning) is 
not needed. I do see that it is quite some effort to rewrite the whole 
"package" of drafts, but the alternative is that implementors get to spend 
more effort on implementation, and those implementations get to waste cpu 
cycles converting between pidf-full and pidf.

Moreover, I have searched but did not find any XML MIME types that use 2 
distinct roots for their XML documents. There seems to be nothing that 
prohibits it, but a unique root is again more simple.

> update would still fail, requiring a resend.

Yes, I meant Accept.

With pidf-full, it's likely that the document will require TCP for 
transmission (due to size). If the server does not support pidf-full, it 
will send an error response, and probably close the connection. Sending 
regular pidf is better, because less wasted bytes are transmitted, and 
because the potential error is postponed (if there are no updates, it never 
occurs). Moreover, the pidf-diff can likely be sent over UDP, avoiding a 
possibly wasteful extra TCP connection setup

Again, given that the goal of the draft is optimization of presence traffic, 
it doesn't make sense to me to not use regular pidf here

---

From: Aki Niemi <[email-masked]>
Date: Mon, 31 Jul 2006 12:41:08 +0300

On su, 2006-07-30 at 18:49 +0200, ext Jeroen van Bemmel wrote:
> complexity. 

The overhead in this case being that the root element is named
<pidf-full> instead of <pidf>, no?

As for complexity, it depends. If your code uses the MIME type to switch
processing modes, then having both full and diff versions as part of the
same MIME type of 'application/pidf-diff+xml' may actually be less
complex to write. (Namely, you would only need to match this new MIME
type, and dump all partial code under that.)

> Given that the purpose of this draft is reduction of message 

I don't understand what you're saying here. In fact, from the
implementation point of view, I'd argue that mixing 'application/pidf
+xml' and 'application/pidf-diff+xml' in the same subscription dialog or
publication stream may require more effort than the current approach,
and make it more error prone as well.

Also, there is no "conversion" between the formats. The partial-pidf
format's XML Schema directly imports the PIDF Schema, so "converting"
from one to the other requires changing the root element from
<pidf-full> to <pidf>, and replacing one namespace declaration. Hardly a
processor intensive task, if you wanted the conversion in the first
place (and I don't think you do).

> prohibits it, but a unique root is again more simple.

Like I said above, this mainly affects how you structure the code
processing these messages. I'd personally prefer switching modes between
notification/publication type (full vs. partial) using the MIME type. 

Then switch between a full replacement and patching using the XML root
element (full vs. diff). YMMV, but I think from implementation POV, this
current approach is actually cleaner.

> transmission (due to size). 

By default, the size difference between a pidf and a pidf-full is 21
bytes:
	- extra '-diff' in the Content-Type
	- extra '-diff' in the namespace declaration
	- extra '-diff' in the root element

With the example presence document in pidf-format, which is (even
without prettyprint) around 1300 bytes, then using pidf-full might just
tip the scales enough that TCP gets used. Then again it might not.

However, I think that always using TCP would be a feature and not a
bug. :) 

> If the server does not support pidf-full, it 
> occurs). 

Right, but only postponed. You haven't actually made the error go away,
which would've convinced me that we should go back and change the
draft(s).

> Moreover, the pidf-diff can likely be sent over UDP, avoiding a 

I think this problem spans way past the discussion of pidf vs. pidf-diff
alone. IMHO, sending anything over UDP is a bad idea, especially
presence traffic. I'm really not convinced that this mixing of TCP and
UDP is a good idea either (e.g., send initial SUBSCRIBE-200-NOTIFY-200
over TCP but then switch to UDP).

Cheers,
Aki

-- 
Aki Niemi
Nokia Research Center

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 31 Jul 2006 20:17:01 +0200

Aki,

OK, so how about a compromise: make pidf-full support optional for publisher 
and notify receiver, and mandatory for presence server to receive.
For NOTIFY, server MUST check accept: in SUBSCRIBE before sending pidf-full

Regards,
Jeroen

----- Original Message ----- 
From: "Aki Niemi" <[email-masked]>
To: "ext Jeroen van Bemmel" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 31, 2006 11:41 AM
Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-05.txt

>> >> pidf in the initial PUBLISH. If a subsequent pidf-diff fails because 
>> >> of
>> >> UAS