Paul Millar [mailto:paul.millar@desy.de] said:
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'm not strongly opposed to this as a concept, but I would make a couple of points. Firstly, many grid protocols don't have RFCs or GFDs so this can't be a universal mechanism. Secondly, as far as I'm aware we so far have only one case, i.e. webdav/http, where there is a real issue, so we should beware of ending up with something which would complicate publishing and querying for the vast majority of cases which work perfectly well already.
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.
I already explained the history of this - we have never defined the usage of InterfaceExtension up to now because it was never needed, but that's no reason not to do it now if we do need it.
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.
Again, I don't think we've ever had a use which required us to define it. I would conceptually see this as going in the opposite direction, in the sense that InterfaceExtensions would be something additional to the basic Interface, whereas a profile would be a restriction or specialisation. Stephen -- Scanned by iCritical.