Paul Millar [mailto:paul.millar@desy.de] said:
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.
Well, to return to the Alice in Wonderland theme, "'When I use a word,' Humpty Dumpty said, in a rather scornful tone,' it means just what I choose it to mean, neither more nor less.'" In the 1.3 schema the definition says this: "The type ACBR t is defined as follows: <PREFIX>:<SNC>. Both <PREFIX> and <SNC> are strings containing no colons and no whitespace. Three types of prefix are already reserved: VOMS to express a VOMS fully qualified attribute name ..." but I don't see why we can't redefine it if we want as long as the definition is clear. Anyway the EGEE proposal https://edms.cern.ch/document/887174/1 already redefines it somewhat by supporting wildcards (recommendation 2).
Sorry, I'm not sufficiently familiar with the "*" usage.
As above - it isn't entirely surprising that you'd be unfamiliar with it since the document is only a couple of months old, and as far as I know hasn't been implemented by anyone yet ...
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)
Well, this whole thing was just a suggestion anyway - the request to suport DENY comes from Nordugrid and Balazs was suggesting a more generic format. However, it isn't especially obvious to me that a different namespace would be better; if you have a parser that can deal with such constructs it would seem a bit odd to have two different schemes when one is a special case of the other, i.e. a rule without any "except" clauses. It would be a bit like saying that a URL with a clause after a ? would need a different scheme to http:.
Although, defining "FQAN predicates" schema probably isn't part of what GLUE should be up to.
It's a dirty job, but someone has to do it :) Stephen