Subject: Re: [Simple] updated buddy list package draft

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Jun 2002 11:32:43 -0400

Sean responded privately; forwarding my reply to the list for discussion.

Sean Olson wrote:
 > I've only taken a very quick glance at the document.
 > My first impression is that we should support this
 > as a template package -- presence.list or something
 > like that.

I also think thats reasonable.

 > I also think we should use multipart/mixed
 > instead of creating a new conglomerated PIDF format.
 > This ties into the notion of a template package
 > because you can subscribe to a list of entities and
 > get event state for those entities in multiple
 > (MIME) documents. Otherwise we have to invent
 > two flavors for every event document format: one
 > for a single document and one for a compound document.

This is listed as one of the open issues in the doc.

The only problem I had with multipart/mixed is that
the conflomerated PIDF format provides some additional
information. Namely, it provides the partial/full flag
and a version number. The partial/full flag is used
to support partial updates. Without it, if you get a NOTIFY
that lists N things in the list, does that mean that there
are only N things on the list (so that you should delete anything
but those N), or just that only those N are being reported (so that you
don't delete anything but those N)?

The version number, we can live without (we can use cseq instead), but
it works better than cseq. Whenever you see a gap in sequence numbers,
and you have partial notifications, you need to trigger a full-state
update. The spec says that this is done in the immediate NOTIFY caused
by a SUBSCRIBE. Now, if we use cseq, we need to trigger full state
updates on gaps in cseq. Gaps in cseq can happen because of a
re-authentication of the NOTIFY at a proxy, for example. So, even though
there is no gap in the document sequence, there is a gap in the cseq
sequence. The result would be a needless full-state update. Not
catastrophic, just wasteful.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Sean Olson" <[email-masked]>
Date: Thu, 27 Jun 2002 23:11:15 -0700

The version information could be a compelling reason to adopt a
composite PIDF
format. This would be made even more compelling if there was a standard
way to handle versioning information across event packages -- even if
this
was constrained to XML only formats.

To be clear, there are several requirements I think should be
considered:

1) Version information that can be used to differentiate event documents
in a
   temporal fashion (this can be considered independently from partial
vs.
   full state)

2) A method for differentiating full state from partial state (perhaps
implicitly)

3) A means to represent a compound document that is a result of 1 or
more
   individual event documents with a uniform and straightforward
procedure
   for recovering the individual documents

4) A means to send a partial update with a uniform and straightforward
   procedure to construct the updated state based on this partial update
   and a previous full state

/sean

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jonathan
Rosenberg
Sent: Thursday, June 27, 2002 8:33 AM
To: Sean Olson; [email-masked]
Subject: Re: [Simple] updated buddy list package draft

Sean responded privately; forwarding my reply to the list for
discussion.

The only problem I had with multipart/mixed is that
the conflomerated PIDF format provides some additional information.
Namely, it provides the partial/full flag and a version number. The
partial/full flag is used to support partial updates. Without it, if you
get a NOTIFY that lists N things in the list, does that mean that there
are only N things on the list (so that you should delete anything but
those N), or just that only those N are being reported (so that you
don't delete anything but those N)?

-Jonathan R.