Subject: [Simple] Comments on Data Manipulation Requirements

From: [email-masked]
Date: Thu, 14 Nov 2002 17:36:25 +0200

Hi,

Section 5.1
REQ 2: This requirement is talking about rejecting a subscriber not belonging in an "Allowed Watchers" list. Should rejecting only be based on subscribers belonging to "Blocked Watchers". In this case, REQ 2 would be changed to talk about adding that subscriber to a "Pending Watchers" list and accepting the subscription. (Or do we need both REQ 2 as it stands and REQ 2 as I suggest?)

REQ 7.7: This is similar to REQ 7 in section 4, should both requirements carry the same strength (MUST or SHOULD)?

REQ 7.8: should it continue specifying that "If the URI cannot be allocated (because it already exists, for example), it MUST be possible to inform the client of the failure, and the reason for it"? This aligns it with REQ 2 in section 4.

REQ 7.9: This is similar to REQ 3 in section 4, should both requirements carry the same strength (MUST or SHOULD)?
REQ 7.9: should it continue specifying that this happens in case user does not provide one? This aligns it with REQ 3 in section 4.

Section 5.2
REQ 4: I don't quite understand this one. Is it talking about filters in subscribe specifying higher rate that the minimum?

Section 5.3
REQ 3: This can result in a NOTIFY with no tuples. Is that Ok? should the NOTIFY be sent? if so, what does it mean?

REQ 4: Tuples cannot be meaningfully identified. Communication means might be a better choice.

Back to section 3:

It states that a PA can receive a subscription with presence list uri. Are we assuming that a PA is a PLS? Does a PA's definition allow for this? This is irrelevant to this draft anyway.

Regards,
Hisham

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Nov 2002 01:48:26 -0500

inline.

[email-masked] wrote:
 > Hi,
 >
 > Section 5.1 REQ 2: This requirement is talking about rejecting a
 > subscriber not belonging in an "Allowed Watchers" list. Should
 > rejecting only be based on subscribers belonging to "Blocked
 > Watchers". In this case, REQ 2 would be changed to talk about adding
 > that subscriber to a "Pending Watchers" list and accepting the
 > subscription. (Or do we need both REQ 2 as it stands and REQ 2 as I
 > suggest?)

I'm not sure I fully understand the question.

I think you are asking about pending watchers. The current acceptance 
requirements don't talk about pending cases. I would add these as 
separate requirements, something like:

REQ XX: It MUST be possible for the acceptance policy to specify that if 
a user is not on a blocked or allowed list, they are pending, such that 
a watcherinfo notification is used to query authorization.

I don't think it makes sense to have an explicit "pending list".

 >
 > REQ 7.7: This is similar to REQ 7 in section 4, should both
 > requirements carry the same strength (MUST or SHOULD)?

Good catch. Generally, I need to make these more consistent.

 >
 > REQ 7.8: should it continue specifying that "If the URI cannot be
 > allocated (because it already exists, for example), it MUST be
 > possible to inform the client of the failure, and the reason for it"?
 > This aligns it with REQ 2 in section 4.

Yes.

 >
 > REQ 7.9: This is similar to REQ 3 in section 4, should both
 > requirements carry the same strength (MUST or SHOULD)? REQ 7.9:
 > should it continue specifying that this happens in case user does not
 > provide one? This aligns it with REQ 3 in section 4.

Yes.

 >
 > Section 5.2 REQ 4: I don't quite understand this one. Is it talking
 > about filters in subscribe specifying higher rate that the minimum?

Its talking about filters in the sense of:
http://www.ietf.org/internet-drafts/draft-moran-sipping-filter-reqs-00.txt

so, if someone asks to be notified about changes only to my geolocation, 
I can reject that subscription.

 >
 > Section 5.3 REQ 3: This can result in a NOTIFY with no tuples. Is
 > that Ok? should the NOTIFY be sent? if so, what does it mean?

I think thats a level deeper than the requirements need to address. I 
suspect that, if the filtering implied that there was no presence 
document left, the NOTIFY would not be sent.

 > might be a better choice.

Well, PIDF doesn't really define communications means either.

This is something that the lonnfors prescaps draft could help us with. 
It would provide a meaningful way to identify tupples. I could specify 
something like "don't report tuples that support voice calls".

 >
 > Back to section 3:
 >
 > It states that a PA can receive a subscription with presence list
 > uri. Are we assuming that a PA is a PLS? Does a PA's definition allow
 > for this? This is irrelevant to this draft anyway.

Its a bit of a stretch of the term PA, since we are applying it to 
something whcih can terminate the presence event package or the 
presence.collection package. Clearly the latter is outside the 
definition provided in the baseline presence spec.

-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