[glue-wg] New Endpoint and Service types

[Paul Millar]

Hi Florido,

On 07/04/14 11:28, Florido Paganelli wrote:
> On 2014-04-04 19:01, Paul Millar wrote:
>> I hope you see how, given any RFC or any GFD, I know exactly how to
>> publish a capability; and, given the capabilities of any endpoint, I
>> know exactly which RFCs and GFDs it supports.
>>
>
> I can see how, indeed.
>
> These that you listed above make more sense for InterfaceName than for
> Capabilities.

Sure, this is my point: currently, capabilities are too high-level and 
there is only one InterfaceName.

> As Stephen pointed out, there is no much additional
> information in the reversed domain name there.

I don't really care about the reversed-domain in the name (see below).

 > [..]
> But since each Endpoint can only have one InterfaceName, then a service
> supporting multiple protocols should in principle have as many Endpoints
> as the supported protocols.

So we're back to the idea of publishing the same information many, many 
times.  Just to be clear: this, at best, an ugly work-around.

Here's an example to put the effect in context.

If a StorageService publish O(10) Endpoints (not unreasonable) and each 
endpoint supports O(10) different RFCs (a tad high, but not 
unreasonable), then publishing an Endpoint for each RFC means publishing 
O(100) *additional* Endpoint objects, each mostly duplicating 
information already published.

> We can overcome the above using capabilities, but then one must me more
> specific on what one can *do* with that protocol:
 >
> Capabilities, the way I read them as they're described in GFD.147, are
> ways to discover functionalities, thus the namespace is not about the
> organization but tells about the functionality.

Two points to consider:

By itself, each RFC document says *very precisely* what functionality is 
supported.  The problem here is that the functionality described by an 
RFC could cover multiple items in the capability namespace and, when 
not, then the choice of capability isn't automatic.

There's nothing to prevent publishing the higher-level functionality in 
addition to the very specific RFC-based capability.

> 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.

Against which capability should a client query to find an endpoint that 
supports RFC-2660 (data.transfer, security.authentication, or both) ?

What does it mean if a storage element publishes 
"data.transfer.rfc-2660" and not "security.authentication.rfc-2660"?

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.

Adding "data.transfer" or "security.authentication" as a prefix is 
problematic as:

   1. protocols often cover multiple high-level functionalities
	(GFD-47 isn't only about data-transfer)

   2. the mapping (RFC-2660 --> "security.authentication") isn't
	automatic, so we're back to maintaining an enumeration.

My view is still that:

   o	An RFC or GFD describes (completely) a set of functionality.

   o	A client's desired interaction is very often predicated on
	an endpoint supporting the functionality described in one
	or more RFC or GFD documents.

   o	That a GLUE2 Endpoint supports multiple RFCs/GFDs
	concurrently is both natural and likely.

   o	There is considerable advantage to publishing the RFCs/GFDs
	that a GLUE2 Endpoint supports, such that:

	  * 	A single Endpoint may publish support for
		multiple RFCs/GFDs.

	  *	Each RFC and each GFD has a single, canonical
		string value that, when published as part of
		Endpoint, represents support for that RFC or
		GFD.

	  *	The canonical value for any RFC or GFD is
		knowable without consulting any enumeration
		(i.e., it is purely algorithmic).

	  *	Given a canonical value, the corresponding RFC
		or GFD is knowable without consulting an
		enumeration.

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.

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.

 > 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 think it is this groups responsibility to either accept or reject my 
view, as expressed above.

Cheers,

Paul.