Re: [Geopriv] Common Policy Update (-10.txt)

[Jonathan Rosenberg <[e-mail]>]

Martin,

I have to disagree with you here. For presence, it is an extremely 
common case that a SUBSCRIBE shows up from a watcher for whom the 
presentity has not yet given any kind of permission either way. The 
purpose of the watcherinfo specification is that the presentity can find 
out about this, and then upload a permission document. The entire point 
of the 'pending' state in that state machine is to handle this 
intermediate period prior to authorization being given (or denied). If, 
as you suggest, the subscription is instead immediately denied, the 
watcher has no way to know when they should try back to determine when 
their subscription is granted (or not). With the pending state, they are 
provided an explicit notification informing them of when this happens.

Thanks,
Jonathan R.

Thomson, Martin wrote:

> With relation to the subscription state machines in RFC 3265 (no
> pretending that this is the context that common policy is targeted
> at) and RFC 3857, it is unclear to me what I am expected to do when
> no rules match.
> 
> My gut says that if you don't have a rule, then you are denied, but
> 3265 states that the "no policy" behaviour is to transition to the
> "pending" state.  So my question is: does no rules imply "no policy"
> or "deny"?
> 
> I would suggest that the answer is "deny" since simple-pres-rules
> provides an explicit way to move to the "pending" state
> (<sub-handling>confirm</sub-handling>).  I'm guessing that this is a
> _safe_ assumption since the "pending" state ultimately leads to
> "terminated" without any further interaction, but this isn't explicit
> anywhere that I can see.
> 
> 
> I also noticed that there's a whoops in Section 10.1:
> 
> Please note that the <identity> element is a condition whereas the
> <id> element is a parameter of that condition.
> ^^^^
> 
> That should be "the <one> element".  Looks like a hangup from a
> previous version.
> 
> Cheers, Martin
> 
> 
>> -----Original Message----- From: Hannes Tschofenig
>> [mailto:[e-mail]] Sent: Tuesday, 25 April 2006
>> 10:08 PM To: [e-mail] Subject: [Geopriv] Common Policy
>> Update (-10.txt)
>> 
>> Hi all,
>> 
>> here is another update to the Common Policy Draft. The changes are:
>> 
>> 
>> - Fixed reference (RFC 2048 to RFC 4288 in Section 15). Allison
>> spotted it. - Incorporated comments from GEN-ART review by Scott
>> Brim. See the separate mail on this subject.
>> 
>> Here is the draft: 
>> http://www.tschofenig.priv.at/TEMP/draft-ietf-geopriv-common-policy-10.txt
>>  
>> http://www.tschofenig.priv.at/TEMP/draft-ietf-geopriv-common-policy-10.html
>> 
>> 
>> Ciao Hannes
>> 
>> 
>> 
>> _______________________________________________ Geopriv mailing
>> list [e-mail] 
>> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 
> ------------------------------------------------------------------------------------------------
>  This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you
> have received it in error, please notify the sender immediately and
> delete the original.  Any unauthorized use of this email is
> prohibited. 
> ------------------------------------------------------------------------------------------------
>  [mf2]
> 
> 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ Geopriv mailing list 
> [e-mail] https://www1.ietf.org/mailman/listinfo/geopriv

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

_______________________________________________
Geopriv mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/geopriv