An STC "when" and "where" example

[Alasdair Allan]

Arnold Rots wrote:
> Alasdair Allan wrote:
>> Arnold Rots wrote:
>>> Alasdair Allan wrote:
>>>> Arnold Rots wrote:
>>>>> Proprietary information, authentication, and restricted acc are is 
>>>>> a whole different kettle of fish; that is a separate discussion.
>>>>
>>>> I don't think it is, it's fundamental to the architecture.
>>>
>>> What's the point of saying: "Something happened but I'm not going to 
>>> tell you what, when, and where"?
>>
>> If one piece of software is talking to another piece of software 
>> there is lots of point. I think you're assuming there will be humans 
>> involved  here. If I dispatch a VOEvent message saying, to 
>> paraphrase, "an event  occurred of type foo", the receiving software 
>> may realise it's  interested in events of type foo, authenticate 
>> itself with the originating server and request further details, a 
>> further more detailed VOEvent message could then be ack'd.
>
> Wouldn't it be simpler to retrict the distribution of the VOEvent?

Depending on the architecture, no not really. Usually it's a lot more 
difficult (too much overhead) to restrict the distribution of a message 
than it is for unauthorised clients, or clients for whom the message is 
not intended, just to ignore it.

> This raises the wider question as to what the place of proprietary 
> information is in the VO.

Something that has, wrongly to my mind, been unjustifiably been 
ignored. A lot of the more interesting data that is out there is 
sitting on astronomer's hard disks and isn't in public archives. I've 
argued for a more peer-to-peer approach to data sharing for a while, 
rather than the top down registry approach which is made for more 
public sources. But really is a different argument.

> So far, I believe, the issue of proprietary data and authentication 
> has only been envisaged in "pull" operations initiated by the client.

Erm, no.

> Here you are talking about intentionally hiding information in "push" 
> operations.  I don't think I like that idea.

I don't see why, the architecture behind it is pretty standard.

> My main original objection was to information that satisfied the three 
> criteria being left out by a service, just because it didn't feel like 
> writing the code to implement its inclusion.

Why should a service operator be forced to put more work into 
implementing a service than is necessary. Why can't they deploy a 
minimal service, they might want to improve and extend it later. But if 
you continue to demand everything up front, deploying any services 
would be extremely difficult and not to be taken lightly.

Perhaps they don't have endless manpower and money to spend on 
deploying what could possibly be a non-core function (at least to 
them). I don't see why the standards should insist they provide what, 
to them, may be additional information that could change a week long 
programming job into a couple of months or more.

If you don't like their terms and conditions a service is being offered 
under, or the information offered by the service, use a different one 
that provides the same (or similar) information. If there isn't one 
then the service provider is doing you a favour by offering the service 
at all, they (probably) don't have to...

>>> If we want to restrict circulation, that may be part of the scheme,  
>>> but is a different aspect.
>>
>> No, it isn't. You can make things mandatory unless they really are  
>> necessary under all use cases. The sort of information you're talking 
>>  about isn't.
>
> I assume you mean "can't".

Yes, I did.

> It is necessary in all cases where coordinate information is 
> transmitted.

But no it isn't.

Al.