Subject: RE: [Simple] new I-D on subscribing to buddy lists

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2001 01:29:15 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, November 15, 2001 8:24 AM
> To: Jonathan Rosenberg; [email-masked]'
> Subject: Re: [Simple] new I-D on subscribing to buddy lists
> 
> From section 2 BLSS Operation:
> > The BLSS generates an immediate, empty NOTIFY as required 
> by [2], and
> then obtains the presence state of the users on the buddy list.
> 
> Does it have done in this order? 

Nope.

> Is there anything which 
> prevents the BLSS
> to subscribe to the buddylist users' presence before the user 
> requests the
> subscription, and send the aggregated state in the first NOTIFY?

Nothing prevents that, no.

> 
> > As notifications with presence data are received, they can be passed
> onwards towards the subscriber.
> 
> Would it be allowable to forward the NOTIFIES from the users 
> subscribed to,
> to the subscriber as is? Would there be a problem with the subscriber
> receiving NOTIFIES with an unknown Call-ID? Or could the BLSS 
> reuse the
> Call-ID from the subscriber?

I think they should be converted. You'll also run into sequence numbering
issues too. The content (the bodies) can simply be copied.

> 
> From section 3.5 Notify bodies:
> > Since the cpim-pidf+xml type contains the identity of the presentity
> within it, it is clear for which buddy the presence data applies.
> 
> It would be nice if this draft could describe the behaviour 
> of the BLSS if
> a presence format used for the body does NOT contain the 
> identity of the
> presentity, but does instead refer to the presentity in the 
> SIP headers.

The point is that this function is not needed, and arguably doesn't belong
in the headers, as its a characteristic of the thing being subscribed to,
which is the buddy list itself.

> 
> > The second possibility for aggregation is to use a single body type
> explicitly designed to support lists of presence data. This format,
> ????....
> 
> Why not use the format proposed to IMPP as specified in the 
> expired draft
> draft-rosenberg-impp-buddylist-00?

That is the wrong thing. draft-rosenberg-impp-buddylist is merely a list of
buddies (effectively, the thing I subscribe to); it is not a way to
represent their presence states.

-Jonathan R.

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Nov 2001 10:13:55 -0600

Inline

> Nothing prevents that, no.

Although there may be some delay between the time the list subscription 
is receivced and the time the BLSS has receivced notifies from each 
presentity in the list. This is fine from a protocol perspective but 
might have some implications on application design.

For that matter, it is probably not necessary to causally couple the 
timing of list subscription (front side) to the presentity subscriptions 
(back side). There are approaches a BLSS implementation could choose to 
increase the odds that it already has presence information for a list 
when the list subscription arrives. One could, for example, have back 
side subscriptions triggered by some other (outside the scope of the 
draft) event, stay up all the time, or keep most lists most recently 
subscribed to active and deactivate lists that have had no subscription 
activity for a long time.

> issues too. The content (the bodies) can simply be copied.

I think they MUST be converted, unless we are prepared to relax rules 
for call-leg matching at the subscriber UA.

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