[glue-wg] New class and attributes for GLUE 2.1/cloud extensions

[stephen.burke at stfc.ac.uk]

Baptiste Grenier [mailto:baptiste.grenier at egi.eu] said:
> But if its not possible/acceptable with regards to existing objects
> let's put it non mandatory. Or maybe can we put it as mandatory and
> have some kind of default value/option set to UNKNOWN? (we tend to prefer
> this to NONE as it is less ambiguous).
> What is the most appropriate?

Making a new attribute mandatory will always cause problems for backward compatibility because it says that an attribute must be present whereas existing info providers won't have it. At least in LDAP it's enforced at the server level, so if info providers don't publish mandatory attributes the whole object is rejected. 

In this case, at the moment we assume X509 authn so it's easy to continue to assume that if nothing different is specified. NONE would be different, you would use it for open services which don't require auth at all - in general that's always likely to be a possibility even if you wouldn't do it for particular services. An unknown value wouldn't make much sense here, anything using a service needs to know what kind of token it needs.

> Probably not, we can put it as an open enumeration with this list of
> values.

That's likely to be better, normally closed enumerations are only for things which are logically complete.

> Does it make sense? If not what would
> do you think would be a more correct way to publish this info?

I was just raising the question - if you say that something is a closed enumeration you aren't allowing a possibility for it to change in future, so you have to be sure that it's complete.

> We were thinking that it could be a port (53) range (0:1024) or a list
> (22,443), that's why it's a string.

OK - but the definition should say explicitly what the allowed formats are.

Stephen