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

The difficult issue here is knowledge of group membership.

As has been proposed earlier, the correct way to say
"everyone in my buddy list *except* Bob" is to literally
have your client send the list of everyone in your buddy
list except Bob. For this specific example, I can agree
with the approach of "just explicitly grant permissions."

Now, if a user wants to semantically say "everyone in engineering
at my company except Bob," it gets much more difficult. From a
user perspective in this case, what he needs to say is "everyone
in engineering except Bob." He doesn't care about the underlying
protocol -- that's the behavior he wants, and anything else is
broken.

To make this model work without an "except" clause, my client
would need to have a mechanism to fetch all the engineering
users from the corporate directory, remove Bob from the list
and enumerate the remainder of them in a grant message.

By my reading, this is basically the solution that advocates
of not using "except" would think is correct.

So, if we take that as a forgone conclusion, the real issue
isn't how long does it take to process rules with exceptions;
rather, the question is: who should expand semantic groups
like "engineering?" Does it make sense for the client to
download the entire several-hundred-member list from the server,
clip one user out of it, and then send it back in a different
format, or to send instructions to the server that say, "take
this list, remove this discrete list of elements from it, and
then install every remaining member as a positive rule"?

I think the key here is that you do *not* need to store the
rules as "group with exceptions." If it makes your processing
model work better, you can trivially expand the group and apply
the exceptions when you receive the message at the server -- and
then everything is reduced to the list of positive statements
that is apparently much easier to implement.

Outlawing the ability to say "except" *will* lead to implementations
that do the horrifically high-bandwidth "fetch, prune, and upload"
client-side exceptions that I describe above -- and, if we don't
have any indicated method for that "fetch" phase, then you *will*
end up with multiple, uninteroperable implementations. (Think of
the case where your client [built into the operating system] and your
server are made by the same large corporation that really likes using
its own proprietary directory service. Is that the direction we want
to drive things?)

/a

(With apologies to all the Bobs out there)

> -----Original Message-----
> From: Andrew Newton [mailto:anewton@ecotroph.net]
> Sent: Friday, November 07, 2003 8:15
> To: Naoko ITO
> Cc: Simple WG; geopriv@ietf.org
> Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth
>
>
> As I recall: at the interim meeting in September we were
> fortunate to
> have two people in attendance that had implemented similar access
> systems. It was their opinion that the 'except' clause adds enough
> processing to be a scalability concern for even moderately loaded
> systems. The fastest systems are able to take a set of rules and
> process them one after another until there is a hit.
>
> Naoko ITO wrote:
> >
> > 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.
>
> Neither do I. But in my opinion, both should be dismissed.
>
> -andy
>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon Nov 10 18:16:21 2003