[glue-wg] New Endpoint and Service types

[Paul Millar]

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.