Hi Stephen, On Monday 14 April 2008 21:57:52 Burke, S (Stephen) wrote:
Paul Millar [mailto:paul.millar@desy.de] said:
VOMS:/atlas/*:EXCEPT:/atlas/higgs
What you describe is an invalid FQAN.
In what sense? Obviously the entire string (/atlas/*:EXCEPT:/atlas/higgs) is not an FQAN
Yes, this is the first point: the complete string is not a valid FQAN. If "VOMS" URI schema means the schema local part is a FQAN, then the example you posted is invalid. That said, I can't find it stated anywhere that the VOMS URI schema *is* a FQAN, this is merely what I remember it being.
but if that were the format then you would parse it into two pieces first (I don't think : is valid in FQANs, although I could be wrong, and you could use some other separator).
Yes, but then you're expecting clients to adopt additional parsing semantics, specifically parse up to the first colon (yes, colon is an illegal character, as is *) and split the text into two parts and process the second based on the "EXCEPT:" token. If VOMS URI means FQAN, you cannot reasonably expect clients to do that. If VOMS URI schema *doesn't* mean this, then there's no problem.
If you mean that /atlas/* isn't a valid FQAN that's true in a strict sense,
Aye.
but it is valid according to the matching rules now being adopted in EGEE.
Sorry, I'm not sufficiently familiar with the "*" usage.
If your point is that you need to know which format is being used, the suggestion was to have two separate PolicyScheme types, one without DENY or equivalent and one with.
Yes, sounds good. If I were to suggest something it would be to extend the name-space (i.e., not use "VOMS" for the URI with the EXCEPT statement) and document the precise format for a "FQAN predicate" (or whatever these are called). URI is extensible, so adding a new schema should be relatively easy. Although, defining "FQAN predicates" schema probably isn't part of what GLUE should be up to. Just my 2c-worth. Cheers, Paul.