[alto] Remaining issue of SSE

Dawn Chan <dawn_chen_f@hotmail.com> Wed, 23 May 2018 08:28 UTC

From: Dawn Chan <dawn_chen_f@hotmail.com>
To: "draft-ietf-alto-incr-update-sse@ietf.org" <draft-ietf-alto-incr-update-sse@ietf.org>, "alto@ietf.org" <alto@ietf.org>
Thread-Topic: Remaining issue of SSE
Thread-Index: AQHT8m+GHph/bFsd9EKTTxapyaNqOw==
Date: Wed, 23 May 2018 08:28:00 +0000
Message-ID: <BLUPR02MB1202BDDCFF048380FB04A009B56B0@BLUPR02MB1202.namprd02.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: d4d70346-2c10-4f39-8c00-e767963926d9
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b5aac61-4f0b-4357-cda9-08d5c08718a6
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: d4d70346-2c10-4f39-8c00-e767963926d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2018 08:28:00.8815 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM03HT138
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/gr0JQiAR6qwyTuZgIgb6O3u1g4U>
Subject: [alto] Remaining issue of SSE
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2018 08:28:08 -0000

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.

Thanks,
Dawn

Re: [alto] Remaining issue of SSE Vijay K. Gurbani
[alto] Remaining issue of SSE Dawn Chan