Subject: RE: [Simple] some additions to the authorization requirements

From: [email-masked]
Date: Tue, 17 Sep 2002 17:33:55 +0300

Hi,

I think the concrete authorization requirements also depend on the structure of the content being authorized.

In my opinion it should be possible to decide which tuples the subscriber would be allowed to receive. (For example I don't want to show everybody that I'm right now available for voice calls.) The differentiation would need to happen based on contact address and in addition based on COMMUNICATION MEANS. As the SIMPLE PIDF profile is not yet defined, it is a bit difficult to give the exact wording but I would suggest something like this:

* the user should be able to specify that the subscriber will only receive notifications containing a combination of a specific contact address and a specific related communication mean. (i.e. only instant messaging but not voice related information.)

Regarding filtering, I think the end result that is delivered to the subscriber should be the combination of subscriber filter and the authorization decision. I'm not sure if accept/reject type of decision is needed for the filter at all, but the  authorization could just set further filters/restrictions.

Regards,
	Markus

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 13 September, 2002 0:11
> To: [email-masked]
> Subject: [Simple] some additions to the authorization requirements
> 
> 
> Folks,
> 
> I'd like to seriously beef up the authorization requirements 
> section of 
> http://www.ietf.org/internet-drafts/draft-rosenberg-simple-dat
> a-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
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>