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

["Thomson, Martin" <[e-mail]>]

I agree, I think that I got my deny/confirm states back to front.  The pending state is safe because you end up in terminated AND you present the option to a user. However, Common Policy is silent on this point (intentionally?).  I think that it's worth pointing out.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[e-mail]]
> Sent: Saturday, 6 May 2006 5:45 AM
> To: Thomson, Martin
> Cc: Hannes Tschofenig; [e-mail]
> Subject: Re: [Geopriv] Common Policy Update (-10.txt)
> 
> 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.com/TEMP/draft-ietf-geopriv-common-policy-10.txt
> >>
> >> http://www.tschofenig.com/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

------------------------------------------------------------------------------------------------
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