RE: [Geopriv] RE: [Simple] Changes in xcap-auth

From: Rosen, Brian ^lt;Brian.Rosen@marconi.com>
Date: Fri Nov 07 2003 - 10:48:41 EST

oh well. Not enough attention paid to spell check!

implantation = implementation

Sorry

Brian

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Friday, November 07, 2003 10:41 AM
> To: 'Henning Schulzrinne'; Naoko ITO
> Cc: Simple WG; geopriv@ietf.org
> Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth
>
>
> I've been on the receiving end of the "broken record".
> I do get it. I have some sympathy, but not a whole lot.
> Basically, I think that "it could be useful", is as
> good as you get, because no one has deployment experience.
> I think you are guilty of having an implantation in mind
> and forcing all requests through the lens of your
> implementation.
>
> One possible way to look at this is to observe that the
> messages sent could express something that is compact,
> where the implementation expands the message to a more
> explicit set of rules. In this example IF (big if)
> you have a list of users, you could have an arbitrarily
> complex set of AND/OR/EXCEPT/... operations, as long
> as the result was reducible to a set of users with
> the permission. That set could then be stored in your
> database.
>
> I do realize that in a sense, this kind of complexity is
> just an opimization, and thus subject to elimination
> in a first phase implementation. However, I think
> that the likelihood here is that it actually matters
> (all of a domain EXCEPT a couple of people).
>
> Brian
>
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Friday, November 07, 2003 10:01 AM
> > To: Naoko ITO
> > Cc: Simple WG; geopriv@ietf.org
> > Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth
> >
> >
> > > I think a separate excepton list is very useful,
> > corresponding to the
> > > exact concept of 'black list.'
> >
> > It is not exactly a black list, although it can be used for
> > that. That's
> > why I called it an exception list.
> >
> > > Still, I'd like to have an except clause in a permission
> statment as
> > > well, which can be used for a differenct purpose, i.e., giving
> > > different permissions to some groups of the watchers.
> >
> > I'm sorry to sound like a broken record: People requesting
> > features that
> > break overall processing models should please have the kindness to
> > provide motivation beyond "it could be useful".
> >
> > >
> > > I don't understand why the except clause in each permission
> > statement
> > > should be dismissed while the separate exception list model can be
> > > supported.
> > >
> > > 1) introducing a separate exception list but not supporting it,
> > > 2) introducing an except clause in each permission but not
> > supporting
> > > it.
> >
> > See my other message.
> >
> > >
> > > In the case of Option #1, the rule enforcer should drop all the
> > > permission statements in the rule set in order to prevent those
> > > should-be-excepted watchers from accidentally obtaining
> > information, if
> > > there is an exception statement which cannot be
> understood. i.e., no
> > > permission is granted to anybody at all. In the case of
> > Option #2, the
> > > rule enforcer should drop the permission statements with
> > unknown except
> > > clauses, which still allows some watchers to obtain
> information. It
> > > seems to me that both options give us the ways to ensure the
> > > privacy-safe even if the rule enforcer does not support the except
> > > mechanism, and rather the latter is more elastic or
> > fault-tolerant. Or
> > > is this just plausible?
> >
> > Please review the discussion on why this doesn't work when
> rules are
> > composed from multiple sources.
> >
> >
> > >
> > > As for maintaining the row-model, I don't think the former model
> > > maintains the row-model, while the entire rule set has no
> meaning if
> > > the actual rule set once has an exception statement. If
> it means not
> > > supporting the exception at all, the same thing can be
> done with the
> > > except clause in each permission.
> >
> > The exception-list model does support the row model. Each rule has
> > exactly one field value for each field, including the URI matching.
> >
> > >
> > > I see no reason to dismiss the latter approach and would
> suggest to
> > > keep both.
> >
> > If you're in Minneapolis, I'd be glad to explain this in more
> > detail in
> > person, since you couldn't be at the interim meeting, where
> > we went over
> > this for several hours...
> >
> > >
> > > Regards,
> > > -----
> > > Naoko Ito / NEC
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri Nov 7 10:50:24 2003

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:24 EST