Subject: Re: [alto] Remaining issue of SSE

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 8 Jun 2018 10:14:08 -0500

[... As individual ...]

Dawn: I prefer option 2 for the following reasons:

a) The "remove" request is sent through the update stream control
 service, therefore it seems appropriate (and expected) to send a
 response through the update stream control service as well.

b) I would rather not conflate the responses at the HTTP layer with the
 responses that are pertinent to the entities processing the HTTP
 bodies.  Responses at the HTTP layer are needed to satisfy the HTTP
 state machinery.  Yes, they can act as hints to the entity processing
 the HTTP body, but my philosophy in protocol design is to be as
 explicit as possible.  Such explicitness calls out for each layer to
 be responsible for its transactions instead of inferring the state of
 a transaction by some exogenous means.

 Doing so may be a bit redundant, but decreases the ambiguity that is
 the bane of protocol design, IMHO.

Cheers,

On 05/23/2018 03:28 AM, Dawn Chan wrote:
> Hi authors of SSE and ALTOers in the working group,
> 
> According to the last ALTO WG meeting, we have a remaining issue
> about SSE. SSE now provides two services, the update stream service
> and the update stream control service. Update stream control service
> allows a client to remove resources or add additional resources. The
> issue is that when the client sends a “remove” request through the
> update stream control service, how will the server inform the client
> that the operation is successful or not. From the last discussion, we
> proposed two response options: When the client sends “remove” request
> to the server, response options are:
> 1.  The server notifies outcome to the client in the HTTP response by
> using an HTTP response code.
> 2. The server notifies outcome to the client in an HTTP response by
> using an HTTP response code and also an update stream message. Curren
> draft adopts option 2.
> 
> The question is: Is it really necessary for the server to send a
> response in the update stream?
> 
> The motivation for the server to send a response in the update stream
> is that there might be the inconsistency between the process dealing
> with the update stream service and the process dealing with the
> update stream control service. So only sending an HTTP response code
> does not really stand for the real actions taken by the update stream
> service. However, personally thinking, such situations only indicate
> the misbehavior of the server rather than the misbehavior of the
> protocol. The server can design its own mechanisms to stay avoid such
> mistake. Thus, adopting option 1 is enough. Do you support option 1?
> It would be great to hear your ideas.

- vijay
--
Vijay K. Gurbani / [email-masked]
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq