Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

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

I think that the answer that you were looking for is this:

Held-context had a few items that I still believe pertain to the minting of the URI, more so than the authorization policy.  Of those three functions you list below:

 -- authorization policy: common-policy is already used by held-context directly
 -- lifetime: managing the lifetime of the created resource is an important problem, and one that goes beyond what is available through policy (even if some of the effects can be mimicked by using policy)
 -- snapshot: I'm yet to see a workable proposal that extends common- or geopriv-policy; I'd love to see one.

Regarding the fundamentals:

The problem I have is the continuing mutation of the HELD locationRequest.  I was perhaps in the minority when it came to deciding that "locationURI" was a location type.  I would have preferred that locationURI was the subject of an entirely separate request (i.e. context creation).  Sure, there are some good reasons for it being as it is, but those are reasons of convenience for the most part.

Thus, on consideration, the largest problem I have with your proposal is that it continues to build on something that is only marginally useful in the first place.  The net result is an increase in complexity, with less to show for it.

However, I see this as constructive input on held-context.  I've been toying with ideas regarding better modularity and use of REST-like principles in its design.  Perhaps there's an opportunity to make some improvements.

--Martin

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Richard Barnes
> Sent: Tuesday, 22 September 2009 7:08 AM
> To: Winterbottom, James
> Cc: GEOPRIV; James M. Polk; Tschofenig,Hannes (NSN - FI/Espoo)
> Subject: Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation
> Policy
> 
> Hm, no, that's not the answer I was looking for.  Here's what I'm
> thinking: Context has basically two parts,
> 1. Protocol mechanics for creating/updating/deleting contexts
> 2. Attributes of contexts that can be set with those mechanics
> 
> I was thinking that (1) could move toward being XCAP, and (2) could
> move
> toward extensions of the policy language.
> 
> In particular, w.r.t. (2), there are only three things that can be set:
> -- "Authorization policy" is already common-policy
> -- "Context lifetime" may require some extension, but is largely the
> same as the <validity> element of common-policy
> -- "Snapshot context" is the most novel, but you could probably still
> implement it with an extension to the <provide-location> element from
> geopriv-policy.
> 
> The protocol mechanics (1) don't do anything really magical; I think
> you
> could map semantics pretty cleanly to a combination of HELD and XCAP.
> 
> --Richard
> 
> 
> 
> Winterbottom, James wrote:
> > Hi Richard,
> >
> > I see Context as a being a container, one of the things of which it
> can contain is a common policy document.
> >
> > Does that help?
> >
> > Cheers
> > James
> >
> >
> > -----Original Message-----
> > From: Richard Barnes [mailto:[e-mail]]
> > Sent: Mon 9/21/2009 3:42 PM
> > To: James M. Polk
> > Cc: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; Hannes
> Tschofenig; GEOPRIV
> > Subject: Re: HELD using XCAP wrt Common Policy/Geolocation Policy
> >
> > James: Don't worry.  Nothing in held-context is getting rid of or
> > duplicating Common Policy.  The difference is that held-context does
> > some things that are not possible today with common-policy or
> > geopriv-policy framework.
> >
> > Hannes/James: Thinking back to the discussions at the Dallas interim
> > some time ago, I thought that there was a motion to move the
> > held-context toward being more of an extension to common-policy,
> rather
> > than an alternative policy transport.  Am I recalling correctly?
> >
> > --Richard
> >
> >
> >
> >
> > James M. Polk wrote:
> >> At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> >>> I could imagine that adding the ability to upload Common
> >>> Policy/Geolocation Policy as an add-on to
> >>> draft-winterbottom-geopriv-held-context-04.txt is a lot easier than
> >>> using XCAP, particularly since I believe that 95% of the cases will
> only
> >>> make usage of a fraction of Common Policy (and nothing from the
> >>> geolocation policy document).
> >> I'm trying to figure out what is being said here in Hannes'
> paragraph
> >> above.
> >>
> >> Is HELD really not needing Common Policy/Geolocation Policy because
> it
> >> has another ID specifying some other mechanism?
> >>
> >> If so, why would this WG allow this?
> >>
> >> Common Policy is supposed to be "common" to everything, right?
> >>
> >> Geolocation Policy is supposed to be used by everything Geopriv
> >> specific, right?
> >>
> >> It appears the net result of this - if true - is that DHCP has to
> jump
> >> through hoops that HELD doesn't, even though HELD can.
> >>
> >> James
> >>
> >>
> >>> Ciao
> >>> Hannes
> >>
> >
> >
> > ---------------------------------------------------------------------
> ---------------------------
> > 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://www.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]