From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <lvasiliev@tarantool.org>
Received: from smtp40.i.mail.ru (smtp40.i.mail.ru [94.100.177.100])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 7BF85441841
 for <tarantool-patches@dev.tarantool.org>;
 Wed, 25 Mar 2020 10:35:44 +0300 (MSK)
References: <cover.1585053742.git.lvasiliev@tarantool.org>
 <7982fc7b062b2424689a990de1f76ca2ff0e4f50.1585053743.git.lvasiliev@tarantool.org>
 <20200324200216.GA18984@atlas>
From: lvasiliev <lvasiliev@tarantool.org>
Message-ID: <178dd6a0-cdee-532c-3d0a-af76062d5f6c@tarantool.org>
Date: Wed, 25 Mar 2020 10:35:41 +0300
MIME-Version: 1.0
In-Reply-To: <20200324200216.GA18984@atlas>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [Tarantool-patches] [PATCH 3/6] iproto: Add negotiation phase
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Konstantin Osipov <kostja.osipov@gmail.com>, alexander.turenko@tarantool.org, tarantool-patches@dev.tarantool.org



On 24.03.2020 23:02, Konstantin Osipov wrote:
> * Leonid Vasiliev <lvasiliev@tarantool.org> [20/03/24 16:02]:
>> The negotiation phase has been added to IPROTO
>>
>> For possibility to have a custom parameters of session the negotiation
>> phase has been added. This is necessary to enable the transmission of
>> an error in different formats(depending on the choice of the client).
>>
>> @TarantoolBot document
>> Title: IPROTO: The negatiation phase
>> For backward compatibility of the data transmission format,
>> the negotiation phase has been added to IPROTO.
>> A new key (IPROTO_NEGOTIATION) has been added to IPROTO command codes.
>> NEGOTIATION BODY: CODE = 0x0E
>> +==========================+
>> |                          |
>> |  NEGOTIATION PARAMETERS  |
>> |                          |
>> +==========================+
>>             MP_MAP
>> Session negotiation parameters are a map with keys like ERROR_FORMAT_VERSION ...
>> The response is a map with all stated negotiation parameters.
>> So, for work with the new format of errors, it is necessary to perform the negotiation phase,
>> otherwise errors will be transmitted in the old format (by default).
> 
> Why not make it a key in IPROTO_AUTH, and require a separate
> round-trip?
Hi. Because it's not a part of AAA.
> 
> Why have it at all and not look at server version, which is part
> of the greeting already?
> 
The cause is backward compatibility.
For example: a client application may expect an error as a string 
(IPROTO_OK case) and instead of which it will receive an error as an 
“object”. A greeting is sent only from the server side to the client, 
but the server must know what format should be used to send errors (what 
format does the client expect).