Hi Florido, More comments in-line. On 07/04/14 14:26, Florido Paganelli wrote: [publishing as Capabilities]
Hence if one has an Endpoint whose interface supports more than one protocol, one could publish:
data.transfer.rfc-2660 security.authentication.rfc-2660 data.transfer.gfd-47 and so on.
What do you think? what do the others think?
First off, having two representations for RFC-2660 (as "data.transfer.rfc-2660" and "security.authentication.rfc-2660") is bad.
is it?
Well, in my humble opinion :)
Against which capability should a client query to find an endpoint that supports RFC-2660 (data.transfer, security.authentication, or both) ?
both -- but I agree is cumbersome, more below
What does it mean if a storage element publishes "data.transfer.rfc-2660" and not "security.authentication.rfc-2660"?
that https is not fully implemented -- however, I just invented those, it does not mean that we shouldn't reason about those. I might agree it makes no sense to have one and not the other. We can just decide that data.transfer.rfc-2660 is enough. Mine was a quickly made up example.
OK, lets move on from this example.
IMHO, there should be a single, canonical way of representing that an endpoint supports RFC-2660 and this should be somehow a single attribute that is published.
ok, but let's try to keep consistency with the string format at least
Sure. At this stage, I'm happy if we can agree that publishing the set of RFCs an Endpoint supports is reasonable thing to do :-) [..]
I don't care so much whether the canonical value is published as Capabilities, InterfaceExtensions, SupportedProfiles or Semantics --- provided precisely one is chosen as the correct way of publishing this information.
But you should care for consistency, that is the key to a winner model.
Firstly, consistent with GFD-147, right? Secondly, consistent with existing enumeration values. In GFD-147, Capability is described explicitly in terms of OGSA architecture classification. OGSA v1.5 spec doesn't include references to RFCs. I would take this to mean we shouldn't publish RFCs under Capability. The description of InterfaceExtension is almost semantically null: "the identification of an extension to the interface protocol supported by the Endpoint." -- there's nothing about what an extension *is*, but there is a hint that this has something to do with protocols. SupportedProfile also has a semantically null description (again, what is a profile?), but I can guess what is meant. RFCs could be published as SupportedProfile legitimately, but this probably wasn't the intention of this attribute. Semantics has the requirement of being human-readable. This isn't a problem for RFCs but, again, probably not what was intended. To me, publishing RFCs as InterfaceExtensions is the option most consistent with GFD-147.
Likewise, I don't care so much whether the canonical value for RFC2660 is 'rfc2660', 'RFC-2660', 'org.ietf.rfc-2660', 'Standards.From-IETF.RFC-2660' or 'http://tools.ietf.org/rfc/rfc2660', provided one purely algorithmic translation is chosen.
I understand all the above comments. However, we are paving the way for GLUE2 to be an unsuccessful schema. The reason is that we keep contradicting what is written in the model, we add hacks and strings the way we like in a non-intuitive way, such that everything can be interpreted in many different ways.
At the risk of repeating myself: I'm advocating having a single, canonical representation for supporting an RFC. This is then not open to being "interpreted in many different ways." It should be defined once and all implementations should use it when publishing their support for an RFC. I'm not sure of this "keep contradicting ..." but for now my interests are in how we publish support for an RFC.
If a capability is a feature then we should enforce that, and not start putting nonsense random strings (org.ogf.rcf-2660 does *not* make sense in that context.)
I don't understand: what do you mean by "a feature"? A Capability is defined in terms of OGSA, so that's clear.
what about
protocol.support.rfc2660
For Capabilities we can't: this string isn't defined in the OGSA v1.5 document. For InterfaceExtensions it's OK (subject to some minor changes) However, for InterfaceExtension the value should be a URI. Technically "protocol.support.rfc2600" is a URL, so a URI; however, it would be better if the value was either a URL with a schema-part or a properly scoped URN.
It would be nice if this is discussed among storage services developers.
There is a meeting coming up, but I'm not sure how much convergence there'll be.
I wouldn't be surprised. The GLUE2 model as we speak is not even able to bring an agreement among those who created it. Why is that, we should maybe ask ourselves (and I was not part of the making of).
I think it is this groups responsibility to either accept or reject my view, as expressed above.
It's the group responsibility to bring sanity in this string mess, not to accept or reject someone's opinion. We should rather try to converge to some consistency for the sake of interoperability.
That's what I'm trying to help facilitate, by providing concrete examples and concrete expressions of what I'm trying to achieve.
WHat do you think about the above formulation, that is, generalize a capability string such as
protocol.support.<protocol name> protocol.supported.<rfc name> protocol.supported.<document name>
If you have better ideas I'd be happy to follow.
I think the fundamental problem with Capability is that it's explicitly tied to OGSA. [..]
protocol.supported.<something> where something is described in the Description field. No additional field in the CSV files.
Sure. Any algorithmic mechanism should also be easy to describe in the CSV file. We should keep this in mind but, at this stage, it shouldn't be such a problem to fulfil that requirement. HTH, Paul.