Subject: [Simple] updated buddy list package draft

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Jun 2002 17:34:39 -0400

Folks,

I've submitted an update to the buddy list event package. As this is now 
a charter item based on our new charter, it also has a new -ietf name. 
Until it appears in the archives, you can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-presencelist-package-00.txt

Some of the changes since the previous version:

* change from the term "buddy list" to "presence list" and "buddy" to 
"presentity" since apparently buddy list is an AOL term.

* specified a new XML document type, using XML schema, that adds list 
capability to PIDF. THis is now a mandatory-to imeplement type for this 
package. You also need to support PIDF and MAY support multipart/mixed.

* a presence-list can contain presentities and also other 
presence-lists. This requires the presence list server (PLS) to itself 
use the presence-list package when subscribing to elements in the list, 
and then backing off to regular presence if that package is not 
supported. This is a potential issue.

* formal specification of algorithm to support partial updates.

* IANA registrations of new namespace and MIME type.

There are several open issues. I will send separate emails on those, one 
per each open issue, in order to facilitate discussion.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Jul 2002 09:25:11 -0400

Jonathan,

Here are some comments about the new spin on this package.

	Paul

- You have the PLS subscribe using the From of its own subscriber. This sounds good, but it limits a significant optimization: If the PLS has many users that subscribe to
the same presence list, and/or if some presentities appear in many lists, the PLS can realize a significant savings by subscribing only once to a particular presentity.
Clearly there are tradeoffs here. Generally I prefer to get things right first and worry about optimizations later. But this may be too big an optimization to forego. 

- One solution to the above may be to use the identity of the owner of the list to subscribe to its elements. The owner then gets to decide who can access the gathered
information. Perhaps we can specify that the definition of a presence list SHOULD (MAY?) specify the expected type of each element.

- It seems ugly to use trial and error to decide whether to subscribe to presencelist or presence. Perhaps the definition of a presence list should be assumed to specify
which is which, with trial and error as a fallback.

- typo: 3.7 still mentions a BLSS.

- typo: 4.1 - reference to watcherinfo seems to be cut/paste error. 

- That same sentence in 4.1, which suggests triggering a full state refresh, ought to be conditional on the received document containing partial state. (If you get one out
of order but with full state, then you don't need to refresh.)

- question: what should a PLS do if a presence list is revised while there are subscriptions outstanding? Presumably it should do a full refresh.

- If a presence list contains references to other presence lists, the resulting presence-list document is flattened - only the top level presence list is named as an
entity. I think it would be better if a <presence-list> contained a mixture of <presence> and <presence-list> elements, reflecting the structure of the actual presence
list.

- Somebody objected to the creation of a new document format because it prevents turning this into a package that can be applied to other event types. I have mixed feelings
about the tradeoffs involved, but *if* that is a goal then I have a suggestion. How about defining a document type that does nothing but describe the hierarchical structure
of the list, together with the version, and possibly a version of each element. Then transmit the values of each revised element, or each element, as separate elements in
multipart/mixed.