Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy
Shida Schubert <shida@ntt-at.com> Mon, 28 September 2009 04:48 UTC
Return-Path: <shida@ntt-at.com>
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7353A682B for <geopriv@core3.amsl.com>; Sun, 27 Sep 2009 21:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZEm+z+jR2QK for <geopriv@core3.amsl.com>; Sun, 27 Sep 2009 21:48:32 -0700 (PDT)
Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.223.26]) by core3.amsl.com (Postfix) with SMTP id 4178A3A6806 for <geopriv@ietf.org>; Sun, 27 Sep 2009 21:48:32 -0700 (PDT)
Received: (qmail 615 invoked from network); 28 Sep 2009 04:59:43 -0000
Received: from gator465.hostgator.com (69.56.174.130) by gateway03.websitewelcome.com with SMTP; 28 Sep 2009 04:59:43 -0000
Received: from fl1-122-135-49-232.tky.mesh.ad.jp ([122.135.49.232]:62750 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from <shida@ntt-at.com>) id 1Ms8BE-0005HC-Rf; Sun, 27 Sep 2009 23:49:45 -0500
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
From: Shida Schubert <shida@ntt-at.com>
In-Reply-To: <001101ca3b52$373aadf0$2c4fa20a@nsnintra.net>
Date: Mon, 28 Sep 2009 13:49:42 +0900
Content-Transfer-Encoding: 7bit
Message-Id: <11E25A26-7D4B-42C8-A23B-1E51E2FF8A52@ntt-at.com>
References: <4AB6D17C.3010109@bbn.com> <024201ca3a82$a6b8f860$b34ba20a@nsnintra.net> <E51D5B15BFDEFD448F90BDD17D41CFF10650E9C3@AHQEX1.andrew.com> <3D3C75174CB95F42AD6BCC56E5555B4501B2E682@FIESEXC015.nsn-intra.net> <XFE-SJC-2122m9lHiu300000508@xfe-sjc-212.amer.cisco.com> <4AB7E537.9060201@bbn.com> <E51D5B15BFDEFD448F90BDD17D41CFF1062C3A8B@AHQEX1.andrew.com> <4AB7EB35.7020200@bbn.com> <001101ca3b52$373aadf0$2c4fa20a@nsnintra.net>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1076)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
Cc: 'GEOPRIV' <geopriv@ietf.org>, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, "'James M. Polk'" <jmpolk@cisco.com>
Subject: Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2009 04:48:33 -0000
Hannes; At BLISS we are trying to define set of URIs along with rules on how these URIs are to be used to enable/disable common features on the proxy (call-forward ON/OFF, voicemail ON/OFF for particular AoR etc.). Each configuration is viewed as a resource, represented as a URI following the REST principle. We are not defining a protocol per se, but trying to provide a simple solution to an interoperability problems observed in a wild, while maintaining forward compatibility to XCAP. So we are neither updating XCAP nor replacing XCAP. Regards Shida On Sep 22, 2009, at 3:59 PM, Hannes Tschofenig wrote: > Hi Richard, > > Regarding (1): The usage of XCAP for the transport instead of the > mechanism > currently described in Context is certain something we could > investigate. I > have not followed the recent work in BLISS but aren't some folks > trying to > invent a new protocol mechanism to update XCAP? > > Regarding (2): I have tried to create such an extension to Common > Policy & > the Gelocation Policy (since I thought it was a good idea after the > discussion we had at the interim meeting) but then the outcome > convinced me > that it isn't. > > Here is the result I came up with about a year ago: > http://www.ietf.org/mail-archive/web/geopriv/current/msg05907.html > > We might want to revisit that very brief discussion and try to the > complexity for implementers. > > Ciao > Hannes > > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: 22 September, 2009 00:08 >> To: Winterbottom, James >> Cc: James M. Polk; Tschofenig, Hannes (NSN - FI/Espoo); Hannes >> Tschofenig; GEOPRIV >> Subject: Re: 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:rbarnes@bbn.com] >>> 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 > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv
- [Geopriv] A modest proposal w.r.t. location URI p… Richard Barnes
- Re: [Geopriv] A modest proposal w.r.t. location U… Hannes Tschofenig
- Re: [Geopriv] A modest proposal w.r.t. location U… Winterbottom, James
- Re: [Geopriv] A modest proposal w.r.t. location U… Tschofenig, Hannes (NSN - FI/Espoo)
- [Geopriv] HELD using XCAP wrt Common Policy/Geolo… James M. Polk
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Richard Barnes
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Winterbottom, James
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Richard Barnes
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Thomson, Martin
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… James M. Polk
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… James M. Polk
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Hannes Tschofenig
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Hannes Tschofenig
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Shida Schubert