From m.b.taylor at bristol.ac.uk  Mon Jul 11 08:13:26 2011
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Mon, 11 Jul 2011 16:13:26 +0100 (BST)
Subject: SAMP 1.3 preparation
Message-ID: <alpine.LRH.2.00.1107111549180.19272@andromeda.star.bris.ac.uk>

Hi SAMPers,

as promised, I'm going through the current SAMP 1.3 WD in accordance
with the decisions made at Naples in May to prepare a version suitable
for promotion through the standards process.

The main difference since the last Recommendation (1.2) is the addition 
of the Web Profile.  The current WD (1.3-20110512) contains a somewhat
detailed but inconclusive discussion of security issues relating to this;
the decision at Naples was to cut this down so that the SAMP standard 
itself contains some discussion of Web Profile security but does not at 
this stage mandate what steps must be taken to address it, at least in 
areas where the best approach is not currently clear.
The details of how security is (or is not) enforced will be left to 
implementations, with the possibility that there may be an IVOA Note 
on best practice at some point following implementation experiences.
If anybody disagrees with this summary of where we agreed to go, please 
shout now.

There are one or two other smaller issues that I'm coming across in
the course of the edit; where appropriate I will discuss these in
separate messages on this list.  You can also follow any updates as
usual in the volute repository
(http://code.google.com/p/volute/source/browse/trunk/projects/samp/doc/samp.tex)

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From m.b.taylor at bristol.ac.uk  Mon Jul 11 09:19:04 2011
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Mon, 11 Jul 2011 17:19:04 +0100 (BST)
Subject: SAMP MType BNF change
Message-ID: <alpine.LRH.2.00.1107111706420.19812@andromeda.star.bris.ac.uk>

The existing version of the standard has the following BNF
in section 3.7 for MType syntax:

   <mchar>  ::= [0-9a-z] | "-" | "_"
   <atom>   ::= <mchar> | <atom> <mchar>
   <mtype>  ::= <atom> | <mtype> "." <atom>

this has the effect that only lower-case MTypes are permitted.
This was probably the intention, but at least two MTypes in common 
use use mixed case:

   table.select.rowList
   coord.pointAt.sky

(see http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampMTypes).

I have therefore changed the <mchar> production to read:

   <mchar> ::= [0-9A-Za-z] | "-" | "_"

(http://code.google.com/p/volute/source/detail?spec=svn1536&r=1536)
since this is unlikely to break anything, and will certainly be less
disruptive than trying to fix all use of mixed-case MTypes in existing
code to match the older definition.

Any objections, please post.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From m.b.taylor at bristol.ac.uk  Tue Jul 12 03:13:45 2011
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Tue, 12 Jul 2011 11:13:45 +0100 (BST)
Subject: SAMP Web Profile register call
Message-ID: <alpine.LRH.2.00.1107121056310.25384@andromeda.star.bris.ac.uk>

Following discussions in Naples I propose to make one change to
the Web Profile API mapping from the 1.3-SAMP-20110512 WD.

In that draft, I had the following signature for the Web Profile 
register call:

    map register(string appName)

that is, the registering application just has to supply a name,
and the hub decides on the basis of that and perhaps on the details
of the HTTP call that it came in on whether to accept registration.
Part (the main part) of that decision will usually be based on 
presenting the name to the user in a popup dialogue.

I propose changing the signature to

   map register(map security-info)

where security-info is a map with a REQUIRED key samp.name, doing
exactly the same job as appName in the previous version.

The effect of this is precisely the same as before, but, it leaves
room for future addition of new optional or required keys to the
security-info map if we come up with other ways to enforce
authentication or other security measures in the future 
(some ideas in this direction came up in Naples), without making 
any disruptive changes to the interface.

I have provisionally made this change at:

   http://code.google.com/p/volute/source/detail?r=1537

If anybody disagrees with the idea or the details, please say so.

As far as implementation goes: I plan in JSAMP to fix it so that
either the new (map) or the old (string) is accepted, 
at least for the short term, so that the few trial Web Profile 
clients out there will continue to work, alongside those using
the newer API which all new Web Profile clients should do.

Luigi, do you think you can do the same in SAMPy?

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From m.b.taylor at bristol.ac.uk  Wed Jul 13 05:35:25 2011
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Wed, 13 Jul 2011 13:35:25 +0100 (BST)
Subject: samp.status=samp.noresponse
Message-ID: <alpine.LRH.2.00.1107131042010.311@andromeda.star.bris.ac.uk>

Section 3.13 of the current SAMP v1.2 Recommendation, in discussing
error processing, has the following wording:

  "In the case of failed calls of the operations defined in Sections
   3.11 and 3.12, for instance syntactically invalid parameters or
   communications failures, hubs and clients SHOULD use the usual
   error reporting mechanisms of the transport protocol in use. Note in
   particular that a samp.status=samp.error-type Response (Section 3.9)
   is only generated by a client processing a received Message, it MUST
   NOT be used by the hub to signal a failed call."

I don't remember if there was a strong motivation for this prohibition
on the Hub originating an error Response.  However it occurs to me that
there is at least one circumstance when it would be a good idea for
it to do so: if the hub has determined in some way that a recipient
client is never going to respond to a pending call/response message 
(for instance because the client has unregistered), it would be good 
if it could inform the sender of that fact.  This would prevent the 
sender waiting for ever for a response which will not arrive.
For an asychronous call/response message using the existing API,
the only way that the hub can pass that information to the sender
is using a hub-generated Response; the reporting mechanisms of
the transport protocol (e.g. XML-RPC Faults) can't be used after
the Call has been received, since the RPC for the Call part has finished.

I therefore suggest:

   1. The last sentence of the quote above be removed or replaced.

   2. The possible values for the Response map samp.status key
      defined in section 3.9 be extended: a new value "samp.noresponse",
      intended only for use in Hub-fabricated responses, should be 
      added alongside samp.ok, samp.warning and samp.error.

Item 2 is debatable - it might be better to use the existing samp.error
status for this purpose, since in most cases the sender would want to
treat a no-response as a kind of error, and this would have less 
potential to disrupt existing code, but my feeling is that the 
additional clarity provided by a status specifically intended for 
this situation is worth the (minor) disruption potential.

I've made a provisional edit to the SAMP document along these lines,
see http://code.google.com/p/volute/source/detail?r=1539

If anyone disagrees with the idea or the details, please say so.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From jfay at microsoft.com  Wed Jul 13 06:55:51 2011
From: jfay at microsoft.com (Jonathan Fay)
Date: Wed, 13 Jul 2011 13:55:51 +0000
Subject: samp.status=samp.noresponse
In-Reply-To: <alpine.LRH.2.00.1107131042010.311@andromeda.star.bris.ac.uk>
References: <alpine.LRH.2.00.1107131042010.311@andromeda.star.bris.ac.uk>
Message-ID: <5AC8AF9D933B124A95DFD9E1F02981611CEE91@TK5EX14MBXC238.redmond.corp.microsoft.com>

I think it is a good concept.

One follow-up question. If a client receives a "samp.noresponse" from the hub, could this be a one-shot issue, or could the recipient client come back at some point?

Put another way; Is it a perminent condition, or a momentary one?

Jonathan

________________________________________
From: apps-samp-bounces at ivoa.net [apps-samp-bounces at ivoa.net] on behalf of Mark Taylor [m.b.taylor at bristol.ac.uk]
Sent: Wednesday, July 13, 2011 5:35 AM
To: apps-samp at ivoa.net
Subject: samp.status=samp.noresponse

Section 3.13 of the current SAMP v1.2 Recommendation, in discussing
error processing, has the following wording:

  "In the case of failed calls of the operations defined in Sections
   3.11 and 3.12, for instance syntactically invalid parameters or
   communications failures, hubs and clients SHOULD use the usual
   error reporting mechanisms of the transport protocol in use. Note in
   particular that a samp.status=samp.error-type Response (Section 3.9)
   is only generated by a client processing a received Message, it MUST
   NOT be used by the hub to signal a failed call."

I don't remember if there was a strong motivation for this prohibition
on the Hub originating an error Response.  However it occurs to me that
there is at least one circumstance when it would be a good idea for
it to do so: if the hub has determined in some way that a recipient
client is never going to respond to a pending call/response message
(for instance because the client has unregistered), it would be good
if it could inform the sender of that fact.  This would prevent the
sender waiting for ever for a response which will not arrive.
For an asychronous call/response message using the existing API,
the only way that the hub can pass that information to the sender
is using a hub-generated Response; the reporting mechanisms of
the transport protocol (e.g. XML-RPC Faults) can't be used after
the Call has been received, since the RPC for the Call part has finished.

I therefore suggest:

   1. The last sentence of the quote above be removed or replaced.

   2. The possible values for the Response map samp.status key
      defined in section 3.9 be extended: a new value "samp.noresponse",
      intended only for use in Hub-fabricated responses, should be
      added alongside samp.ok, samp.warning and samp.error.

Item 2 is debatable - it might be better to use the existing samp.error
status for this purpose, since in most cases the sender would want to
treat a no-response as a kind of error, and this would have less
potential to disrupt existing code, but my feeling is that the
additional clarity provided by a status specifically intended for
this situation is worth the (minor) disruption potential.

I've made a provisional edit to the SAMP document along these lines,
see http://code.google.com/p/volute/source/detail?r=1539

If anyone disagrees with the idea or the details, please say so.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From m.b.taylor at bristol.ac.uk  Wed Jul 13 07:07:59 2011
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Wed, 13 Jul 2011 15:07:59 +0100 (BST)
Subject: samp.status=samp.noresponse
In-Reply-To: <5AC8AF9D933B124A95DFD9E1F02981611CEE91@TK5EX14MBXC238.redmond.corp.microsoft.com>
References: <alpine.LRH.2.00.1107131042010.311@andromeda.star.bris.ac.uk>
	<5AC8AF9D933B124A95DFD9E1F02981611CEE91@TK5EX14MBXC238.redmond.corp.microsoft.com>
Message-ID: <alpine.LRH.2.00.1107131502070.1457@andromeda.star.bris.ac.uk>

Permanent.  It would be an error to have more than one response to a 
single call, so the hub certainly shouldn't send a samp.noresponse
at one point followed by a response with a different status later.
If there's any chance that a real response might arrive in the
future, the hub should not send a samp.noresponse response.

In the case of the client that unregisters without replying:
if it re-registers it can't supply a response to a message it 
received during its previous period of registration, since 
on re-registering it will have a different client ID, and hence
be as far as the hub and any other clients are concerned a 
different client.

Mark

On Wed, 13 Jul 2011, Jonathan Fay wrote:

> I think it is a good concept.
> 
> One follow-up question. If a client receives a "samp.noresponse" from the hub, could this be a one-shot issue, or could the recipient client come back at some point?
> 
> Put another way; Is it a perminent condition, or a momentary one?
> 
> Jonathan
> 
> ________________________________________
> From: apps-samp-bounces at ivoa.net [apps-samp-bounces at ivoa.net] on behalf of Mark Taylor [m.b.taylor at bristol.ac.uk]
> Sent: Wednesday, July 13, 2011 5:35 AM
> To: apps-samp at ivoa.net
> Subject: samp.status=samp.noresponse
> 
> Section 3.13 of the current SAMP v1.2 Recommendation, in discussing
> error processing, has the following wording:
> 
>   "In the case of failed calls of the operations defined in Sections
>    3.11 and 3.12, for instance syntactically invalid parameters or
>    communications failures, hubs and clients SHOULD use the usual
>    error reporting mechanisms of the transport protocol in use. Note in
>    particular that a samp.status=samp.error-type Response (Section 3.9)
>    is only generated by a client processing a received Message, it MUST
>    NOT be used by the hub to signal a failed call."
> 
> I don't remember if there was a strong motivation for this prohibition
> on the Hub originating an error Response.  However it occurs to me that
> there is at least one circumstance when it would be a good idea for
> it to do so: if the hub has determined in some way that a recipient
> client is never going to respond to a pending call/response message
> (for instance because the client has unregistered), it would be good
> if it could inform the sender of that fact.  This would prevent the
> sender waiting for ever for a response which will not arrive.
> For an asychronous call/response message using the existing API,
> the only way that the hub can pass that information to the sender
> is using a hub-generated Response; the reporting mechanisms of
> the transport protocol (e.g. XML-RPC Faults) can't be used after
> the Call has been received, since the RPC for the Call part has finished.
> 
> I therefore suggest:
> 
>    1. The last sentence of the quote above be removed or replaced.
> 
>    2. The possible values for the Response map samp.status key
>       defined in section 3.9 be extended: a new value "samp.noresponse",
>       intended only for use in Hub-fabricated responses, should be
>       added alongside samp.ok, samp.warning and samp.error.
> 
> Item 2 is debatable - it might be better to use the existing samp.error
> status for this purpose, since in most cases the sender would want to
> treat a no-response as a kind of error, and this would have less
> potential to disrupt existing code, but my feeling is that the
> additional clarity provided by a status specifically intended for
> this situation is worth the (minor) disruption potential.
> 
> I've made a provisional edit to the SAMP document along these lines,
> see http://code.google.com/p/volute/source/detail?r=1539
> 
> If anyone disagrees with the idea or the details, please say so.
> 
> Mark
> 
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From luigi at lambrate.inaf.it  Wed Jul 13 08:08:29 2011
From: luigi at lambrate.inaf.it (Luigi Paioro)
Date: Wed, 13 Jul 2011 17:08:29 +0200
Subject: samp.status=samp.noresponse
In-Reply-To: <alpine.LRH.2.00.1107131042010.311@andromeda.star.bris.ac.uk>
References: <alpine.LRH.2.00.1107131042010.311@andromeda.star.bris.ac.uk>
Message-ID: <4E1DB4ED.6030900@lambrate.inaf.it>

This is a good point, and from a general point of view probably the 
option 2 is preferable, but, as you say, it could raise some problem in 
existing code (not able to recognize samp.noresponse key). I'm a bit 
concerned about this issue. A possible option could be to return a 
samp.error with a well know samp.code and samp.errortxt. I cannot figure 
out another backward compatible solution.

Luigi


Il 07/13/11 14:35, Mark Taylor ha scritto:
> Section 3.13 of the current SAMP v1.2 Recommendation, in discussing
> error processing, has the following wording:
>
>    "In the case of failed calls of the operations defined in Sections
>     3.11 and 3.12, for instance syntactically invalid parameters or
>     communications failures, hubs and clients SHOULD use the usual
>     error reporting mechanisms of the transport protocol in use. Note in
>     particular that a samp.status=samp.error-type Response (Section 3.9)
>     is only generated by a client processing a received Message, it MUST
>     NOT be used by the hub to signal a failed call."
>
> I don't remember if there was a strong motivation for this prohibition
> on the Hub originating an error Response.  However it occurs to me that
> there is at least one circumstance when it would be a good idea for
> it to do so: if the hub has determined in some way that a recipient
> client is never going to respond to a pending call/response message
> (for instance because the client has unregistered), it would be good
> if it could inform the sender of that fact.  This would prevent the
> sender waiting for ever for a response which will not arrive.
> For an asychronous call/response message using the existing API,
> the only way that the hub can pass that information to the sender
> is using a hub-generated Response; the reporting mechanisms of
> the transport protocol (e.g. XML-RPC Faults) can't be used after
> the Call has been received, since the RPC for the Call part has finished.
>
> I therefore suggest:
>
>     1. The last sentence of the quote above be removed or replaced.
>
>     2. The possible values for the Response map samp.status key
>        defined in section 3.9 be extended: a new value "samp.noresponse",
>        intended only for use in Hub-fabricated responses, should be
>        added alongside samp.ok, samp.warning and samp.error.
>
> Item 2 is debatable - it might be better to use the existing samp.error
> status for this purpose, since in most cases the sender would want to
> treat a no-response as a kind of error, and this would have less
> potential to disrupt existing code, but my feeling is that the
> additional clarity provided by a status specifically intended for
> this situation is worth the (minor) disruption potential.
>
> I've made a provisional edit to the SAMP document along these lines,
> see http://code.google.com/p/volute/source/detail?r=1539
>
> If anyone disagrees with the idea or the details, please say so.
>
> Mark

From m.b.taylor at bristol.ac.uk  Wed Jul 13 08:25:06 2011
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Wed, 13 Jul 2011 16:25:06 +0100 (BST)
Subject: samp.status=samp.noresponse
In-Reply-To: <4E1DB4ED.6030900@lambrate.inaf.it>
References: <alpine.LRH.2.00.1107131042010.311@andromeda.star.bris.ac.uk>
	<4E1DB4ED.6030900@lambrate.inaf.it>
Message-ID: <alpine.LRH.2.00.1107131612430.5018@andromeda.star.bris.ac.uk>

Luigi,

I'd resist declaring a well-known samp.errortxt value, since that 
should probably be free text, and in any case it may be useful to 
inform the user exactly what's happened (client has unregistered, 
message state discarded because of hub memory limits, something else...).

A well-known samp.code for this purpose as you suggest would however 
do the trick, and is fully backward compatible.  It feels a little bit
untidy to me, but it's not a bad idea.

Since the samp.status entry is declared as an extensible vocabulary,
client code ought to be prepared to deal with values other than
samp.ok, samp.warning and samp.error.  However, I agree, in practice
it's possible that it won't.  Do you (or anybody else) have a feeling
for whether this is likely to cause problems for existing code
in practice?

Mark

On Wed, 13 Jul 2011, Luigi Paioro wrote:

> This is a good point, and from a general point of view probably the option 2
> is preferable, but, as you say, it could raise some problem in existing code
> (not able to recognize samp.noresponse key). I'm a bit concerned about this
> issue. A possible option could be to return a samp.error with a well know
> samp.code and samp.errortxt. I cannot figure out another backward compatible
> solution.
> 
> Luigi
> 
> 
> Il 07/13/11 14:35, Mark Taylor ha scritto:
> > Section 3.13 of the current SAMP v1.2 Recommendation, in discussing
> > error processing, has the following wording:
> > 
> >    "In the case of failed calls of the operations defined in Sections
> >     3.11 and 3.12, for instance syntactically invalid parameters or
> >     communications failures, hubs and clients SHOULD use the usual
> >     error reporting mechanisms of the transport protocol in use. Note in
> >     particular that a samp.status=samp.error-type Response (Section 3.9)
> >     is only generated by a client processing a received Message, it MUST
> >     NOT be used by the hub to signal a failed call."
> > 
> > I don't remember if there was a strong motivation for this prohibition
> > on the Hub originating an error Response.  However it occurs to me that
> > there is at least one circumstance when it would be a good idea for
> > it to do so: if the hub has determined in some way that a recipient
> > client is never going to respond to a pending call/response message
> > (for instance because the client has unregistered), it would be good
> > if it could inform the sender of that fact.  This would prevent the
> > sender waiting for ever for a response which will not arrive.
> > For an asychronous call/response message using the existing API,
> > the only way that the hub can pass that information to the sender
> > is using a hub-generated Response; the reporting mechanisms of
> > the transport protocol (e.g. XML-RPC Faults) can't be used after
> > the Call has been received, since the RPC for the Call part has finished.
> > 
> > I therefore suggest:
> > 
> >     1. The last sentence of the quote above be removed or replaced.
> > 
> >     2. The possible values for the Response map samp.status key
> >        defined in section 3.9 be extended: a new value "samp.noresponse",
> >        intended only for use in Hub-fabricated responses, should be
> >        added alongside samp.ok, samp.warning and samp.error.
> > 
> > Item 2 is debatable - it might be better to use the existing samp.error
> > status for this purpose, since in most cases the sender would want to
> > treat a no-response as a kind of error, and this would have less
> > potential to disrupt existing code, but my feeling is that the
> > additional clarity provided by a status specifically intended for
> > this situation is worth the (minor) disruption potential.
> > 
> > I've made a provisional edit to the SAMP document along these lines,
> > see http://code.google.com/p/volute/source/detail?r=1539
> > 
> > If anyone disagrees with the idea or the details, please say so.
> > 
> > Mark
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From jfay at microsoft.com  Wed Jul 13 08:34:04 2011
From: jfay at microsoft.com (Jonathan Fay)
Date: Wed, 13 Jul 2011 15:34:04 +0000
Subject: samp.status=samp.noresponse
In-Reply-To: <alpine.LRH.2.00.1107131502070.1457@andromeda.star.bris.ac.uk>
References: <alpine.LRH.2.00.1107131042010.311@andromeda.star.bris.ac.uk>
	<5AC8AF9D933B124A95DFD9E1F02981611CEE91@TK5EX14MBXC238.redmond.corp.microsoft.com>
	<alpine.LRH.2.00.1107131502070.1457@andromeda.star.bris.ac.uk>
Message-ID: <5AC8AF9D933B124A95DFD9E1F02981611CEFFC@TK5EX14MBXC238.redmond.corp.microsoft.com>

I meant pertaining to future messages. Should it be implied that a no response means any further attempt to send messages to that recipient would also be fruitless?

Jonathan

-----Original Message-----
From: Mark Taylor [mailto:mbt at star.bris.ac.uk] On Behalf Of Mark Taylor
Sent: Wednesday, July 13, 2011 7:08 AM
To: Jonathan Fay
Cc: apps-samp at ivoa.net
Subject: RE: samp.status=samp.noresponse

Permanent.  It would be an error to have more than one response to a single call, so the hub certainly shouldn't send a samp.noresponse at one point followed by a response with a different status later.
If there's any chance that a real response might arrive in the future, the hub should not send a samp.noresponse response.

In the case of the client that unregisters without replying:
if it re-registers it can't supply a response to a message it received during its previous period of registration, since on re-registering it will have a different client ID, and hence be as far as the hub and any other clients are concerned a different client.

Mark

On Wed, 13 Jul 2011, Jonathan Fay wrote:

> I think it is a good concept.
> 
> One follow-up question. If a client receives a "samp.noresponse" from the hub, could this be a one-shot issue, or could the recipient client come back at some point?
> 
> Put another way; Is it a perminent condition, or a momentary one?
> 
> Jonathan
> 
> ________________________________________
> From: apps-samp-bounces at ivoa.net [apps-samp-bounces at ivoa.net] on 
> behalf of Mark Taylor [m.b.taylor at bristol.ac.uk]
> Sent: Wednesday, July 13, 2011 5:35 AM
> To: apps-samp at ivoa.net
> Subject: samp.status=samp.noresponse
> 
> Section 3.13 of the current SAMP v1.2 Recommendation, in discussing 
> error processing, has the following wording:
> 
>   "In the case of failed calls of the operations defined in Sections
>    3.11 and 3.12, for instance syntactically invalid parameters or
>    communications failures, hubs and clients SHOULD use the usual
>    error reporting mechanisms of the transport protocol in use. Note in
>    particular that a samp.status=samp.error-type Response (Section 3.9)
>    is only generated by a client processing a received Message, it MUST
>    NOT be used by the hub to signal a failed call."
> 
> I don't remember if there was a strong motivation for this prohibition 
> on the Hub originating an error Response.  However it occurs to me 
> that there is at least one circumstance when it would be a good idea 
> for it to do so: if the hub has determined in some way that a 
> recipient client is never going to respond to a pending call/response 
> message (for instance because the client has unregistered), it would 
> be good if it could inform the sender of that fact.  This would 
> prevent the sender waiting for ever for a response which will not arrive.
> For an asychronous call/response message using the existing API, the 
> only way that the hub can pass that information to the sender is using 
> a hub-generated Response; the reporting mechanisms of the transport 
> protocol (e.g. XML-RPC Faults) can't be used after the Call has been 
> received, since the RPC for the Call part has finished.
> 
> I therefore suggest:
> 
>    1. The last sentence of the quote above be removed or replaced.
> 
>    2. The possible values for the Response map samp.status key
>       defined in section 3.9 be extended: a new value "samp.noresponse",
>       intended only for use in Hub-fabricated responses, should be
>       added alongside samp.ok, samp.warning and samp.error.
> 
> Item 2 is debatable - it might be better to use the existing 
> samp.error status for this purpose, since in most cases the sender 
> would want to treat a no-response as a kind of error, and this would 
> have less potential to disrupt existing code, but my feeling is that 
> the additional clarity provided by a status specifically intended for 
> this situation is worth the (minor) disruption potential.
> 
> I've made a provisional edit to the SAMP document along these lines, 
> see http://code.google.com/p/volute/source/detail?r=1539
> 
> If anyone disagrees with the idea or the details, please say so.
> 
> Mark
> 
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-928-8776 
> http://www.star.bris.ac.uk/~mbt/

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/


From m.b.taylor at bristol.ac.uk  Wed Jul 13 08:42:50 2011
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Wed, 13 Jul 2011 16:42:50 +0100 (BST)
Subject: samp.status=samp.noresponse
In-Reply-To: <5AC8AF9D933B124A95DFD9E1F02981611CEFFC@TK5EX14MBXC238.redmond.corp.microsoft.com>
References: <alpine.LRH.2.00.1107131042010.311@andromeda.star.bris.ac.uk>
	<5AC8AF9D933B124A95DFD9E1F02981611CEE91@TK5EX14MBXC238.redmond.corp.microsoft.com>
	<alpine.LRH.2.00.1107131502070.1457@andromeda.star.bris.ac.uk>
	<5AC8AF9D933B124A95DFD9E1F02981611CEFFC@TK5EX14MBXC238.redmond.corp.microsoft.com>
Message-ID: <alpine.LRH.2.00.1107131635360.5216@andromeda.star.bris.ac.uk>

No, that's not what I had in mind.  Some reasons for believing that a
future response will not arrive might suggest that the client in question
is out of action for good, and others might not.  My intention here is
just to allow the hub to generate and pass back a response for a 
single message which will never get a client-generated response.
No further conclusions are implicit in such a response.

On Wed, 13 Jul 2011, Jonathan Fay wrote:

> I meant pertaining to future messages. Should it be implied that a no response means any further attempt to send messages to that recipient would also be fruitless?
> 
> Jonathan
> 
> -----Original Message-----
> From: Mark Taylor [mailto:mbt at star.bris.ac.uk] On Behalf Of Mark Taylor
> Sent: Wednesday, July 13, 2011 7:08 AM
> To: Jonathan Fay
> Cc: apps-samp at ivoa.net
> Subject: RE: samp.status=samp.noresponse
> 
> Permanent.  It would be an error to have more than one response to a single call, so the hub certainly shouldn't send a samp.noresponse at one point followed by a response with a different status later.
> If there's any chance that a real response might arrive in the future, the hub should not send a samp.noresponse response.
> 
> In the case of the client that unregisters without replying:
> if it re-registers it can't supply a response to a message it received during its previous period of registration, since on re-registering it will have a different client ID, and hence be as far as the hub and any other clients are concerned a different client.
> 
> Mark
> 
> On Wed, 13 Jul 2011, Jonathan Fay wrote:
> 
> > I think it is a good concept.
> > 
> > One follow-up question. If a client receives a "samp.noresponse" from the hub, could this be a one-shot issue, or could the recipient client come back at some point?
> > 
> > Put another way; Is it a perminent condition, or a momentary one?
> > 
> > Jonathan
> > 
> > ________________________________________
> > From: apps-samp-bounces at ivoa.net [apps-samp-bounces at ivoa.net] on 
> > behalf of Mark Taylor [m.b.taylor at bristol.ac.uk]
> > Sent: Wednesday, July 13, 2011 5:35 AM
> > To: apps-samp at ivoa.net
> > Subject: samp.status=samp.noresponse
> > 
> > Section 3.13 of the current SAMP v1.2 Recommendation, in discussing 
> > error processing, has the following wording:
> > 
> >   "In the case of failed calls of the operations defined in Sections
> >    3.11 and 3.12, for instance syntactically invalid parameters or
> >    communications failures, hubs and clients SHOULD use the usual
> >    error reporting mechanisms of the transport protocol in use. Note in
> >    particular that a samp.status=samp.error-type Response (Section 3.9)
> >    is only generated by a client processing a received Message, it MUST
> >    NOT be used by the hub to signal a failed call."
> > 
> > I don't remember if there was a strong motivation for this prohibition 
> > on the Hub originating an error Response.  However it occurs to me 
> > that there is at least one circumstance when it would be a good idea 
> > for it to do so: if the hub has determined in some way that a 
> > recipient client is never going to respond to a pending call/response 
> > message (for instance because the client has unregistered), it would 
> > be good if it could inform the sender of that fact.  This would 
> > prevent the sender waiting for ever for a response which will not arrive.
> > For an asychronous call/response message using the existing API, the 
> > only way that the hub can pass that information to the sender is using 
> > a hub-generated Response; the reporting mechanisms of the transport 
> > protocol (e.g. XML-RPC Faults) can't be used after the Call has been 
> > received, since the RPC for the Call part has finished.
> > 
> > I therefore suggest:
> > 
> >    1. The last sentence of the quote above be removed or replaced.
> > 
> >    2. The possible values for the Response map samp.status key
> >       defined in section 3.9 be extended: a new value "samp.noresponse",
> >       intended only for use in Hub-fabricated responses, should be
> >       added alongside samp.ok, samp.warning and samp.error.
> > 
> > Item 2 is debatable - it might be better to use the existing 
> > samp.error status for this purpose, since in most cases the sender 
> > would want to treat a no-response as a kind of error, and this would 
> > have less potential to disrupt existing code, but my feeling is that 
> > the additional clarity provided by a status specifically intended for 
> > this situation is worth the (minor) disruption potential.
> > 
> > I've made a provisional edit to the SAMP document along these lines, 
> > see http://code.google.com/p/volute/source/detail?r=1539
> > 
> > If anyone disagrees with the idea or the details, please say so.
> > 
> > Mark
> > 
> > --
> > Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> > m.b.taylor at bris.ac.uk +44-117-928-8776 
> > http://www.star.bris.ac.uk/~mbt/
> 
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
> 
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From luigi at lambrate.inaf.it  Wed Jul 13 09:10:23 2011
From: luigi at lambrate.inaf.it (Luigi Paioro)
Date: Wed, 13 Jul 2011 18:10:23 +0200
Subject: samp.status=samp.noresponse
In-Reply-To: <alpine.LRH.2.00.1107131612430.5018@andromeda.star.bris.ac.uk>
References: <alpine.LRH.2.00.1107131042010.311@andromeda.star.bris.ac.uk>
	<4E1DB4ED.6030900@lambrate.inaf.it>
	<alpine.LRH.2.00.1107131612430.5018@andromeda.star.bris.ac.uk>
Message-ID: <4E1DC36F.6050404@lambrate.inaf.it>

Well, actually clients code should be ready to receive values other than 
samp.ok, etc. but I'm not sure I've been so careful writing the clients 
code I have. However this is not really an issue for me, since if I find 
a problem I can promptly fix it. I am rather concerned about the code 
written by others. In any case, if I am the only one worried about this, 
that's OK, samp.noresponse is a good option.

Cheers,

   Luigi


Il 07/13/11 17:25, Mark Taylor ha scritto:
> Luigi,
>
> I'd resist declaring a well-known samp.errortxt value, since that
> should probably be free text, and in any case it may be useful to
> inform the user exactly what's happened (client has unregistered,
> message state discarded because of hub memory limits, something else...).
>
> A well-known samp.code for this purpose as you suggest would however
> do the trick, and is fully backward compatible.  It feels a little bit
> untidy to me, but it's not a bad idea.
>
> Since the samp.status entry is declared as an extensible vocabulary,
> client code ought to be prepared to deal with values other than
> samp.ok, samp.warning and samp.error.  However, I agree, in practice
> it's possible that it won't.  Do you (or anybody else) have a feeling
> for whether this is likely to cause problems for existing code
> in practice?
>
> Mark
>
> On Wed, 13 Jul 2011, Luigi Paioro wrote:
>
>> This is a good point, and from a general point of view probably the option 2
>> is preferable, but, as you say, it could raise some problem in existing code
>> (not able to recognize samp.noresponse key). I'm a bit concerned about this
>> issue. A possible option could be to return a samp.error with a well know
>> samp.code and samp.errortxt. I cannot figure out another backward compatible
>> solution.
>>
>> Luigi
>>
>>
>> Il 07/13/11 14:35, Mark Taylor ha scritto:
>>> Section 3.13 of the current SAMP v1.2 Recommendation, in discussing
>>> error processing, has the following wording:
>>>
>>>     "In the case of failed calls of the operations defined in Sections
>>>      3.11 and 3.12, for instance syntactically invalid parameters or
>>>      communications failures, hubs and clients SHOULD use the usual
>>>      error reporting mechanisms of the transport protocol in use. Note in
>>>      particular that a samp.status=samp.error-type Response (Section 3.9)
>>>      is only generated by a client processing a received Message, it MUST
>>>      NOT be used by the hub to signal a failed call."
>>>
>>> I don't remember if there was a strong motivation for this prohibition
>>> on the Hub originating an error Response.  However it occurs to me that
>>> there is at least one circumstance when it would be a good idea for
>>> it to do so: if the hub has determined in some way that a recipient
>>> client is never going to respond to a pending call/response message
>>> (for instance because the client has unregistered), it would be good
>>> if it could inform the sender of that fact.  This would prevent the
>>> sender waiting for ever for a response which will not arrive.
>>> For an asychronous call/response message using the existing API,
>>> the only way that the hub can pass that information to the sender
>>> is using a hub-generated Response; the reporting mechanisms of
>>> the transport protocol (e.g. XML-RPC Faults) can't be used after
>>> the Call has been received, since the RPC for the Call part has finished.
>>>
>>> I therefore suggest:
>>>
>>>      1. The last sentence of the quote above be removed or replaced.
>>>
>>>      2. The possible values for the Response map samp.status key
>>>         defined in section 3.9 be extended: a new value "samp.noresponse",
>>>         intended only for use in Hub-fabricated responses, should be
>>>         added alongside samp.ok, samp.warning and samp.error.
>>>
>>> Item 2 is debatable - it might be better to use the existing samp.error
>>> status for this purpose, since in most cases the sender would want to
>>> treat a no-response as a kind of error, and this would have less
>>> potential to disrupt existing code, but my feeling is that the
>>> additional clarity provided by a status specifically intended for
>>> this situation is worth the (minor) disruption potential.
>>>
>>> I've made a provisional edit to the SAMP document along these lines,
>>> see http://code.google.com/p/volute/source/detail?r=1539
>>>
>>> If anyone disagrees with the idea or the details, please say so.

From m.b.taylor at bristol.ac.uk  Fri Jul 15 04:45:06 2011
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Fri, 15 Jul 2011 12:45:06 +0100 (BST)
Subject: SAMP 1.3 security discussion changes
Message-ID: <alpine.LRH.2.00.1107151234150.28759@andromeda.star.bris.ac.uk>

I've made some security-related adjustments to the Web Profile section
in the SAMP 1.3 WD.

 - Discussion of security in section 5.4 somewhat reworked and reduced
   as agreed in Naples, with a note that further research on security
   is ongoing.

 - Recommendation that all non-localhost requests to the Web Profile
   hub HTTP server be rejected (403 Forbidden), since there is no
   legitimate access to this server except from the local host.

 - Provision that the URL translation service MAY block access to 
   sensitive resources (e.g. some parts of the local filesystem)
   for security reasons (403 Forbidden).

You can see the changes on volute 
(http://code.google.com/p/volute/source/detail?r=1540).
Comments welcome.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From m.b.taylor at bristol.ac.uk  Tue Jul 26 05:30:36 2011
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Tue, 26 Jul 2011 13:30:36 +0100 (BST)
Subject: samp.hub.event.shutdown usage
Message-ID: <alpine.LRH.2.00.1107261319110.11917@andromeda.star.bris.ac.uk>

The samp.hub.event.shutdown MType is documented as follows in the SAMP
doc:

    The hub SHOULD broadcast this message just before it exits.
    The hub SHOULD make every effort to broadcast this message even in
    case of an exit due to an error condition.

I have provisionally added the following sentence:

    It SHOULD also send it to clients who are registered using a
    given profile if that profile is about to shut down, even if
    the hub itself will continue to operate.

(http://code.google.com/p/volute/source/detail?r=1543)

Since multiple profiles can operate as part of a hub, and in
principle some might start and stop at different times than the
hub itself, it will be desirable for the hub to inform affected
clients about profile shutdown for the same reasons as for hub
shutdown, that is, that the client is going to be unable to
continue to communicate with the hub.

You could argue that the samp.hub.disconnect MType would be more
appropriate here.  My feeling is that samp.hub.event.shutdown is
better, since profile shutdown, like hub shutdown, but unlike forcible
disconnection, has the implication that immediate re-connection
attempts are likely to fail.

Post here if anyone disagrees.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From m.b.taylor at bristol.ac.uk  Tue Jul 26 06:22:52 2011
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Tue, 26 Jul 2011 14:22:52 +0100 (BST)
Subject: samp.status=samp.noresponse
In-Reply-To: <4E1DC36F.6050404@lambrate.inaf.it>
References: <alpine.LRH.2.00.1107131042010.311@andromeda.star.bris.ac.uk>
	<4E1DB4ED.6030900@lambrate.inaf.it>
	<alpine.LRH.2.00.1107131612430.5018@andromeda.star.bris.ac.uk>
	<4E1DC36F.6050404@lambrate.inaf.it>
Message-ID: <alpine.LRH.2.00.1107261419150.12441@andromeda.star.bris.ac.uk>

Luigi,

on reflection, I think your idea is best, since it keeps the
straightforward ok/warning/error status.  I've altered the text so 
that in case of a non-forthcoming recipient response the hub 
should generate a response with samp.status=samp.error and 
samp.code=samp.noresponse.  The change is visible at
http://code.google.com/p/volute/source/detail?r=1544

Mark

On Wed, 13 Jul 2011, Luigi Paioro wrote:

> Well, actually clients code should be ready to receive values other than
> samp.ok, etc. but I'm not sure I've been so careful writing the clients code I
> have. However this is not really an issue for me, since if I find a problem I
> can promptly fix it. I am rather concerned about the code written by others.
> In any case, if I am the only one worried about this, that's OK,
> samp.noresponse is a good option.
> 
> Cheers,
> 
>   Luigi
> 
> 
> Il 07/13/11 17:25, Mark Taylor ha scritto:
> > Luigi,
> > 
> > I'd resist declaring a well-known samp.errortxt value, since that
> > should probably be free text, and in any case it may be useful to
> > inform the user exactly what's happened (client has unregistered,
> > message state discarded because of hub memory limits, something else...).
> > 
> > A well-known samp.code for this purpose as you suggest would however
> > do the trick, and is fully backward compatible.  It feels a little bit
> > untidy to me, but it's not a bad idea.
> > 
> > Since the samp.status entry is declared as an extensible vocabulary,
> > client code ought to be prepared to deal with values other than
> > samp.ok, samp.warning and samp.error.  However, I agree, in practice
> > it's possible that it won't.  Do you (or anybody else) have a feeling
> > for whether this is likely to cause problems for existing code
> > in practice?
> > 
> > Mark
> > 
> > On Wed, 13 Jul 2011, Luigi Paioro wrote:
> > 
> > > This is a good point, and from a general point of view probably the option
> > > 2
> > > is preferable, but, as you say, it could raise some problem in existing
> > > code
> > > (not able to recognize samp.noresponse key). I'm a bit concerned about
> > > this
> > > issue. A possible option could be to return a samp.error with a well know
> > > samp.code and samp.errortxt. I cannot figure out another backward
> > > compatible
> > > solution.
> > > 
> > > Luigi
> > > 
> > > 
> > > Il 07/13/11 14:35, Mark Taylor ha scritto:
> > > > Section 3.13 of the current SAMP v1.2 Recommendation, in discussing
> > > > error processing, has the following wording:
> > > > 
> > > >     "In the case of failed calls of the operations defined in Sections
> > > >      3.11 and 3.12, for instance syntactically invalid parameters or
> > > >      communications failures, hubs and clients SHOULD use the usual
> > > >      error reporting mechanisms of the transport protocol in use. Note
> > > > in
> > > >      particular that a samp.status=samp.error-type Response (Section
> > > > 3.9)
> > > >      is only generated by a client processing a received Message, it
> > > > MUST
> > > >      NOT be used by the hub to signal a failed call."
> > > > 
> > > > I don't remember if there was a strong motivation for this prohibition
> > > > on the Hub originating an error Response.  However it occurs to me that
> > > > there is at least one circumstance when it would be a good idea for
> > > > it to do so: if the hub has determined in some way that a recipient
> > > > client is never going to respond to a pending call/response message
> > > > (for instance because the client has unregistered), it would be good
> > > > if it could inform the sender of that fact.  This would prevent the
> > > > sender waiting for ever for a response which will not arrive.
> > > > For an asychronous call/response message using the existing API,
> > > > the only way that the hub can pass that information to the sender
> > > > is using a hub-generated Response; the reporting mechanisms of
> > > > the transport protocol (e.g. XML-RPC Faults) can't be used after
> > > > the Call has been received, since the RPC for the Call part has
> > > > finished.
> > > > 
> > > > I therefore suggest:
> > > > 
> > > >      1. The last sentence of the quote above be removed or replaced.
> > > > 
> > > >      2. The possible values for the Response map samp.status key
> > > >         defined in section 3.9 be extended: a new value
> > > > "samp.noresponse",
> > > >         intended only for use in Hub-fabricated responses, should be
> > > >         added alongside samp.ok, samp.warning and samp.error.
> > > > 
> > > > Item 2 is debatable - it might be better to use the existing samp.error
> > > > status for this purpose, since in most cases the sender would want to
> > > > treat a no-response as a kind of error, and this would have less
> > > > potential to disrupt existing code, but my feeling is that the
> > > > additional clarity provided by a status specifically intended for
> > > > this situation is worth the (minor) disruption potential.
> > > > 
> > > > I've made a provisional edit to the SAMP document along these lines,
> > > > see http://code.google.com/p/volute/source/detail?r=1539
> > > > 
> > > > If anyone disagrees with the idea or the details, please say so.
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From luigi at lambrate.inaf.it  Tue Jul 26 07:05:12 2011
From: luigi at lambrate.inaf.it (Luigi Paioro)
Date: Tue, 26 Jul 2011 16:05:12 +0200
Subject: samp.status=samp.noresponse
In-Reply-To: <alpine.LRH.2.00.1107261419150.12441@andromeda.star.bris.ac.uk>
References: <alpine.LRH.2.00.1107131042010.311@andromeda.star.bris.ac.uk>	<4E1DB4ED.6030900@lambrate.inaf.it>	<alpine.LRH.2.00.1107131612430.5018@andromeda.star.bris.ac.uk>	<4E1DC36F.6050404@lambrate.inaf.it>
	<alpine.LRH.2.00.1107261419150.12441@andromeda.star.bris.ac.uk>
Message-ID: <4E2EC998.7010305@lambrate.inaf.it>

Hi Mark,

   it looks like a good compromise to me.

Cheers,

   Luigi


Il 07/26/11 15:22, Mark Taylor ha scritto:
> Luigi,
>
> on reflection, I think your idea is best, since it keeps the
> straightforward ok/warning/error status.  I've altered the text so
> that in case of a non-forthcoming recipient response the hub
> should generate a response with samp.status=samp.error and
> samp.code=samp.noresponse.  The change is visible at
> http://code.google.com/p/volute/source/detail?r=1544
>
> Mark
>
> On Wed, 13 Jul 2011, Luigi Paioro wrote:
>
>> Well, actually clients code should be ready to receive values other than
>> samp.ok, etc. but I'm not sure I've been so careful writing the clients code I
>> have. However this is not really an issue for me, since if I find a problem I
>> can promptly fix it. I am rather concerned about the code written by others.
>> In any case, if I am the only one worried about this, that's OK,
>> samp.noresponse is a good option.
>>
>> Cheers,
>>
>>    Luigi
>>
>>
>> Il 07/13/11 17:25, Mark Taylor ha scritto:
>>> Luigi,
>>>
>>> I'd resist declaring a well-known samp.errortxt value, since that
>>> should probably be free text, and in any case it may be useful to
>>> inform the user exactly what's happened (client has unregistered,
>>> message state discarded because of hub memory limits, something else...).
>>>
>>> A well-known samp.code for this purpose as you suggest would however
>>> do the trick, and is fully backward compatible.  It feels a little bit
>>> untidy to me, but it's not a bad idea.
>>>
>>> Since the samp.status entry is declared as an extensible vocabulary,
>>> client code ought to be prepared to deal with values other than
>>> samp.ok, samp.warning and samp.error.  However, I agree, in practice
>>> it's possible that it won't.  Do you (or anybody else) have a feeling
>>> for whether this is likely to cause problems for existing code
>>> in practice?
>>>
>>> Mark
>>>
>>> On Wed, 13 Jul 2011, Luigi Paioro wrote:
>>>
>>>> This is a good point, and from a general point of view probably the option
>>>> 2
>>>> is preferable, but, as you say, it could raise some problem in existing
>>>> code
>>>> (not able to recognize samp.noresponse key). I'm a bit concerned about
>>>> this
>>>> issue. A possible option could be to return a samp.error with a well know
>>>> samp.code and samp.errortxt. I cannot figure out another backward
>>>> compatible
>>>> solution.
>>>>
>>>> Luigi
>>>>
>>>>
>>>> Il 07/13/11 14:35, Mark Taylor ha scritto:
>>>>> Section 3.13 of the current SAMP v1.2 Recommendation, in discussing
>>>>> error processing, has the following wording:
>>>>>
>>>>>      "In the case of failed calls of the operations defined in Sections
>>>>>       3.11 and 3.12, for instance syntactically invalid parameters or
>>>>>       communications failures, hubs and clients SHOULD use the usual
>>>>>       error reporting mechanisms of the transport protocol in use. Note
>>>>> in
>>>>>       particular that a samp.status=samp.error-type Response (Section
>>>>> 3.9)
>>>>>       is only generated by a client processing a received Message, it
>>>>> MUST
>>>>>       NOT be used by the hub to signal a failed call."
>>>>>
>>>>> I don't remember if there was a strong motivation for this prohibition
>>>>> on the Hub originating an error Response.  However it occurs to me that
>>>>> there is at least one circumstance when it would be a good idea for
>>>>> it to do so: if the hub has determined in some way that a recipient
>>>>> client is never going to respond to a pending call/response message
>>>>> (for instance because the client has unregistered), it would be good
>>>>> if it could inform the sender of that fact.  This would prevent the
>>>>> sender waiting for ever for a response which will not arrive.
>>>>> For an asychronous call/response message using the existing API,
>>>>> the only way that the hub can pass that information to the sender
>>>>> is using a hub-generated Response; the reporting mechanisms of
>>>>> the transport protocol (e.g. XML-RPC Faults) can't be used after
>>>>> the Call has been received, since the RPC for the Call part has
>>>>> finished.
>>>>>
>>>>> I therefore suggest:
>>>>>
>>>>>       1. The last sentence of the quote above be removed or replaced.
>>>>>
>>>>>       2. The possible values for the Response map samp.status key
>>>>>          defined in section 3.9 be extended: a new value
>>>>> "samp.noresponse",
>>>>>          intended only for use in Hub-fabricated responses, should be
>>>>>          added alongside samp.ok, samp.warning and samp.error.
>>>>>
>>>>> Item 2 is debatable - it might be better to use the existing samp.error
>>>>> status for this purpose, since in most cases the sender would want to
>>>>> treat a no-response as a kind of error, and this would have less
>>>>> potential to disrupt existing code, but my feeling is that the
>>>>> additional clarity provided by a status specifically intended for
>>>>> this situation is worth the (minor) disruption potential.
>>>>>
>>>>> I've made a provisional edit to the SAMP document along these lines,
>>>>> see http://code.google.com/p/volute/source/detail?r=1539
>>>>>
>>>>> If anyone disagrees with the idea or the details, please say so.

From m.b.taylor at bristol.ac.uk  Tue Jul 26 07:07:40 2011
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Tue, 26 Jul 2011 15:07:40 +0100 (BST)
Subject: Next SAMP 1.3 WD imminent?
Message-ID: <alpine.LRH.2.00.1107261456530.12921@andromeda.star.bris.ac.uk>

Hi all,

I think I've mostly stopped tinkering with the SAMP document for now,
and I plan to submit substantially the current version as a revised
1.3 Working Draft to the IVOA document repository in the next few days,
unless anybody objects.  I'd expect this to be quite close to the
version which eventually gets promoted to PR and hopefully REC
(RFC some time towards the next Interop), though of course any 
comments or implementation experience which arise between now and 
then can be accommodated.

If anybody wants alterations or more time for disucssion before
the next WD is published please say so, otherwise I'll go ahead.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/