Subject: RE: [Geopriv] Comments on draft-ietf-geopriv-policy-00

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 28 Oct 2003 17:44:07 -0500

Actually, I think wildcards will be very useful.
Generally, I am likely to afford anyone in Marconi some level of information
about my current location.  In addition, we do have local scope in our
domain hierarchy, such that there is a domain which represents my group,
which would get a more accurate rendition of my location.  Furthermore,
as there is no other mechanism provided, it would be in our interest to
at least create aliases in our local uri scheme to facilitate this
kind of mechanism, as it would be much more efficient than repeating rows
in the database.

I do understand your concern about linear search.  Most databases allow
REGEXPs in a WHERE clause.  Even more allow a LIKE element.  There are some 
that don't, and that it would be slower in such cases.  That's a tradeoff.  
My favorite RDMSs would work, YMMV.

I don't agree with your concerns on allowing multiple values for URI
or any other condition.  Every database allows an OR in the WHERE,
which would be exactly what you would use.

Allowing a URI list parameter to a Distribute allows you to specify
TO WHOM you will allow onward distribution of a LO.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, October 28, 2003 2:38 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: [Geopriv] Comments on draft-ietf-geopriv-policy-00
> 
> 
> Rosen, Brian wrote:
> 
> > Substance:
> > Has there been discussion of wildcards in the URI of the requestor?
> > It would seem this would be pretty important, as in most cases, you
> > will specify a rule to a class of recipients, and wildcarded uri's
> > are the easiest way to classify. "[email-masked]" is a pretty useful
> > URI for a requester, while enumerating all the uri's in example.com
> > might be quite difficult.  Regexps would seem to be appropriate for
> > a string match.
> 
> While the discussion isn't reflected in depth, the authors discussed 
> this in some detail. This also came up at the interim meeting.
> 
> I have two concerns with allowing wildcards:
> 
> - I have not seen a convincing use case. For all but the 
> tiniest domain, 
> you wouldn't give access to everybody in that domain, e.g., in your 
> company or everybody within AOL. If the number of people is 
> small, you 
> might as well enumerate them. Would you really have a rule for all of 
> marconi.com, interns, cleaning staff and your boss included?
> 
> - Efficiency: the auth format is designed to be evaluated very 
> efficiently for large sets of rules. As soon as you add 
> regexp, you need 
> to do a linear search and evaluation, rather than a simple 
> indexed/hashed search and probably decrease efficiency by an order of 
> magnitude.
> 
> > 
> > In the same vein, it would be very helpful to be able to have
> > more than one URI in the <applies-to> which would be an inclusive OR
> > of any of the specified targets.  You might like to get fancy with
> > other conditions, but I suspect that is too complicated.  A single
> > list of URIs is pretty simple.  The same could reasonably be
> > applied to the other conditions, with somewhat less usefulness.
> > Sphere is an example where it would be more useful, civil slightly
> > less so.
> 
> This is an optimization that adds no fundamental capability, 
> as the same 
> effect can be achieved by having multiple rows which differ in the 
> <applies-to> element only. However, as soon as you allow multiple 
> values, the matching algorithm breaks and, for example, a 
> database-like 
> matching mechanism does not work any more.
> 
> I've tried very hard to keep this in canonical relational 
> database form, 
> as this is easy to reason about in terms of matching and there are 
> known, large-scale implementations with a wealth of performance 
> optimizations.
> 
> Indeed, as is, one implementation of this is extremely 
> trivial: convert 
> XML one-to-one into database records, apply SELECT. 
> (Naturally, this is 
> not required, but it certainly beats the model of searching through 
> thousands of records sequentially, evaluating each one.)
> 
> Also, the more variation in rules, the harder it is to render 
> this. One 
> name is easy to ask for on a web form, multiple names gets 
> tricky to do, 
> as you'll always have some kind of upper limit on the count. 
> Thus, from 
> a UI perspective, having a single value per field simplifies the 
> implementation.
> 
> > 
> > Why can you have a parameter to a "Retention Time", but not a URI
> > list to "Distribute"?
> 
> I'm not sure what you mean by the latter.
> 
> > 
> > Nits:
> 
> I'll fold those into the next version.
> 
> > 
> > Goals and Assumptions, Permit only has a sentence fragment
> > "However, to avoid complex conflict resolution with these rules 
> > only 'permit'."  Probably should add "is specified" or something
> > similar.
> > 
> > Goals and Assumptions, Additive Permissions has a misplaced comma:
> > "If several rules fire then, the location recipient obtains the
> > permissions of all rules."  Probably should be "..fire, then..."
> > 
> > The word "action" is overloaded, or at least confusing in the text
> > "Since only one type of action i.e. 'permit' is 
> > allowed it does not need to be represented. 
> > ... Actions cause the location server to take a certain action, 
> > such as adding a subscription." 
> > One cannot have "one only one kind of action" and "certain action, 
> > such as".  I'm actually not sure what was intended.  Perhaps
> > other actions are possible, each of which also assumes 'permit'.
> > 
> > In 4.1, the caution is somewhat misleading, or at least confusing.
> > It may right itself when we actually produce a document describing
> > a civil LO.  Until then, you could revise the wording to make it
> > clear that you are including this definition solely for the purpose
> > of naming the fields, which are referenced in later sections in 
> > rules.
> > 
> > The text twice states "street level precision", but actually it
> > goes to floor, and has the LOC field for Room.
> > 
> > BTW, I would really like to see a better definition of LOC
> > when we get to it.
> 
> Agreed. Thanks for the comments.
> 
> > 
> > Brian
> > 
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Oct 2003 17:51:20 -0500

Brian,

you got the query and the data reversed, I think: While all databases 
allow LIKE and REGEXP searches for data, here the rules are the content 
(rows in the database) and the requester (and other relevant 
information) is the query.

I don't know of any database that allows the data objects themselves to 
be regexp's or be multi-valued, for example.

Henning