Subject: [Simple] some additions to the authorization requirements

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Sep 2002 17:11:22 -0400

Folks,

I'd like to seriously beef up the authorization requirements section of 
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-00.txt 
to discuss a lot more of the specifics we want to accomplish.

The key thing is details on the level of permissions that are being 
granted by the presentity. Some additional requirements to consider:

* the user should be able to specify that the subscriber will only 
receive notifications containing a specific contact address (i.e., only 
my work phone)

* the user should be able to specify that the subscriber will only 
receive notifications containing a specific status type (basic, for 
example, which is the only status type defined so far).

* the user should be able to specify that the subscriber will only 
receive notifications containing specific values of a specific status 
type (for example, only report when my status goes to OPEN, not CLOSED)

* the user should be able to specify that the subscriber will or will 
not receive a contact address in the notifications.

Effectively, the above rules all specify filters or triggers on the 
presence documents that should be sent to a particular presentity.

We could specify rate-based filters (i.e., specify that a subscriber 
cannot receive documents more frequently than X per minute), but this 
doesn't seem awfully useful.

Related to that, if the SUBSCRIBE contained a filter of some sort, the 
authorization should allow the user to approve or reject their filter, 
and possibly impose further filtering as above.

Thanks,
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: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Sep 2002 19:14:54 -0400

below...

> granted by the presentity. Some additional requirements to consider:

Seems like a good direction in general.

> receive notifications containing a specific contact address (i.e., only

Good, but may be hard to define. My work phone may not always have the same contact address (because of DHCP and lack of an assigned DNS name.) May need to identify in some other way - e.g. via the credential used to register it. (I don't like that alternative much, but I'm grasping for something other than the contact address itself.)

(Unfortunately devices without DNS names are not especially unusual. Not just phones, but Microsoft devices that use WINS rather than DNS.) 

> example, which is the only status type defined so far).

fine.

> type (for example, only report when my status goes to OPEN, not CLOSED)

This might be troublesome. What happens if, when I first subscribe, the status only contains values I am not permitted to receive? I have to receive a notification of some sort, and every tuple is required to carry some status. So I think the entire tuple must be suppressed if there are no status values that can be returned. When the status changes, I should get a notification again if the value I had previously received is different than what I would receive if I polled now. 

Perhaps this requirement could be reworded to solve this problem:

 * the user should be able to specify the specific values of a
   specific status type that the subscribe IS, or IS NOT, permitted
   to receive. Values not permitted must be omitted from the status
   in notifications. If all status is omitted, the tuple must be 
   omitted as well. (for example, include tuples with OPEN status,
   but suppress those with only CLOSED status.)

> not receive a contact address in the notifications.

yes - good.

> and possibly impose further filtering as above.

Is there any reason to forbid filtering requests from the subscriber?

Would make more sense to me to just require that if both sides supply filters than they must be composed - the document must be passed through both. As long as a filter only removes things it doesn't matter what order they are applied.

	Paul