Re: [Sipping] Expiration of permissions in consent

If we compare we today's e-mail, I am subscribed to a mailing list that 
sends me e-mail to my inbox, which I can access from any device with the 
appropriate connectivity.

If we put expiration time to the permisions, then I would need to 
refresh these permisions from a given UA when the permision is over. If 
I change the UA, I would need to reconfigure with all the permisions I 
had granted in the past, to keep refreshing them. And what about if this 
other UA does not support the consent framework operations? Or I would 
need a synchronization mechanism that keeps me informed across different 
UAs of the expiration time, when there isn't an active subscription.

In the meantime, when my permission is expired, people might be try to 
contact the list (including me), but because my permision expired, I 
will not receive those requests. This creates a discontinued service and 
bad user experience.

In my opinion, there is too much hassle here ... I would rather go for 
something similar to how mailing lists work today, which effectively 
means removing requirement 7.

/Miguel

Gonzalo Camarillo wrote:
> Folks,
> 
> there is a last open issue in the consent requirements draft:
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-consent-reqs-01.txt
> 
> The open issue has to do with requirement number 7:
> 
>    REQ 7: It shall be possible for the users to specify that permissions
>       are time limited, and must be refreshed after expiration.
> 
> The idea is that the relays storing consent state for a particular user 
> do not need to be in the same administrative domain as the user. 
> Therefore, the state information to be stored should be as little as 
> possible. That's why we have removed allowed operations from the 
> permission documents.
> 
> Now, storing expiration information requires a little more logic in the 
> relay, but, on the other hand, having permissions that expire could be a 
> useful feature in some scenarios.
> 
> The open issue is: do we keep or remove REQ 7?
> 
> Note that when you subscribe to an email mailing list, you do not 
> typically set any expiration time for your subscription. So, I lean 
> towards removing REQ 7 but do not have a strong opinion.
> 
> Opinions?
> 
> Thanks,
> 
> Gonzalo
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP