Re: [AVTCORE] Francesca Palombini's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT)

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Wed, 19 May 2021 19:35 UTC

Return-Path: <gunnar.hellstrom@ghaccess.se>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CC83A1C88; Wed, 19 May 2021 12:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuFG6zx7VeUW; Wed, 19 May 2021 12:35:33 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1D63A1C66; Wed, 19 May 2021 12:35:31 -0700 (PDT)
Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 93A962094C; Wed, 19 May 2021 21:35:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621452927; bh=jC0vDAfAjvWoeOrZdGAeBzChZOeWH5ZN2njPHuMv6kA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=k5Mo1WEkM1Ig3m4sjse//C2iLO7LIzeR4DlMR3puOmn3VXjwjhFfdJc97FS/d4HBY YDfSp/VilMFJJfbADD/GW70J8K4/EFuCdY35r9uS4ulJP0YaVTu3R1ieEjjhbSCYhS viwMqUxU7OLkr+1E8YHiowM1in5qHaj5lPbNxuwk=
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Francesca Palombini <francesca.palombini@ericsson.com>, The IESG <iesg@ietf.org>, avtcore-chairs@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, IETF AVTCore WG <avt@ietf.org>
References: <162137008198.8563.14104995910062091869@ietfa.amsl.com> <e0a8256f-976a-3b95-7f50-2e37f5f3bead@ghaccess.se> <CAKKJt-fWiJYDr3AU-8jcENSXCsNfHADd-BrgT+GARyekWFmNOg@mail.gmail.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <f218c302-bdf4-d6ac-628f-d2e9d042bd1b@ghaccess.se>
Date: Wed, 19 May 2021 21:35:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <CAKKJt-fWiJYDr3AU-8jcENSXCsNfHADd-BrgT+GARyekWFmNOg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------B3324FE3971859D5B905FA78"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/D5CvYZwLok1LA2Sz_70r5mUx_Ps>
Subject: Re: [AVTCORE] Francesca Palombini's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2021 19:35:49 -0000

Spencer and Francesca,

Thanks for the edit proposal. Since Francesca accepts it, I will include 
it in next version.

If my further comments inline do not lead to one more change.

Den 2021-05-19 kl. 15:48, skrev Spencer Dawkins at IETF:
> I apologize for asking, but ...
>
> On Tue, May 18, 2021 at 4:43 PM Gunnar Hellström 
> <gunnar.hellstrom@ghaccess.se <mailto:gunnar.hellstrom@ghaccess.se>> 
> wrote:
>
>     Francesca,
>
>     thank you for your review. I will answer your question 6 here, and
>     follow up soon with a new version with actions on all comments.
>
>     Den 2021-05-18 kl. 22:34, skrev Francesca Palombini via Datatracker:
>     > Francesca Palombini has entered the following ballot position for
>     > draft-ietf-avtcore-multi-party-rtt-mix-18: No Objection
>     >
>     > When responding, please keep the subject line intact and reply
>     to all
>     > email addresses included in the To and CC lines. (Feel free to
>     cut this
>     > introductory paragraph, however.)
>     >
>     >
>     > Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>     > for more information about DISCUSS and COMMENT positions.
>     >
>     >
>     > The document, along with other ballot positions, can be found here:
>     >
>     https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>     <https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/>
>     >
>     >
>     >
>     >
>     ----------------------------------------------------------------------
>     > COMMENT:
>     >
>     ----------------------------------------------------------------------
>     >
>     > Thank you for the work on this document. I have some minor
>     non-blocking
>     > comments (feel free to take them or leave them), but I'd like
>     some response to
>     > point 6. about the normative MUST.
>     >
>     > Francesca
>     ....
>     > 6. -----
>     >
>     >     the stream.  Some of them are optional. Implementations MUST
>     be able
>     >     to ignore optional control codes that they do not support.
>     >
>     > FP: I am really unsure how this MUST can be verified for
>     interoperability.
>     > Maybe this does not need to be a BCP 14 MUST?
>
>
> Gunnar,
>
> When I read your response to Francesca's comment, my next question was 
> whether an implementation should always ignore optional control codes 
> that they do not support, if *not* ignoring them just cause problems, 
> displays garbage characters, etc.
>
> If that's correct, I'm not Francesca, of course, but I'd think 
> "Implementations MUST ignore optional control codes that they do not 
> support" would be verifiable for interoperability, and would justify a 
> BCP 14 MUST..

Yes, that is the case and the edit looks good.

I forgot to comment on the kernel of Francesca's comment. "Can it be 
verified"? Yes, a test generator can include control codes of the 
different specified types, and the verification would be that the ones 
supported have the intentional effect and the unsupported ones do not 
cause any visible effects and do not cause malfunction in the receiver. 
As usual with testing you need to restrict the variations of the values 
in these control codes to a realistic number.

Is "ignore" a too weak word here. It is an active discarding with 
knowledge about the syntax of the control codes that is required, so 
that everything from start to end can be discarded.

Would it be better to change "ignore" to "discard" or "skip"?

Regards

Gunnar

>
> Best,
>
> Spencer
>
>     Yes, this MUST is intended to be a normative MUST. And it is very
>     important but not that complicated to properly ignore unsupported
>     control codes.
>
>     The control codes are specified in ITU-T T.140, in turn
>     referencing to
>     ISO 6429. The control codes often consist of a special leading
>     character, followed by a parameter consisting of normal text
>     characters,
>     and then a final special character.
>
>     Ignoring an unsupported control code means that the app needs to
>     understand the structure of control codes, so that it ignores
>     everything
>     from the leading special character to and including the final special
>     character.
>
>     It would be incorrect and cause garbage in the display or even
>     malfunction if it just ignored the leading special character and then
>     interpreted the characters in the parameter as if it was text and
>     tried
>     to present it.
>
>     The control codes can imply change in color or blinking or other
>     visible
>     effects in the text, and it is said that such effects are optional.
>
>
>     Would more explaining text be required for this section?
>
>
>     Regards
>
>     Gunnar
>
>     >
>     >
>     >
>     > _______________________________________________
>     > Audio/Video Transport Core Maintenance
>     > avt@ietf.org <mailto:avt@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/avt
>     <https://www.ietf.org/mailman/listinfo/avt>
>
>     -- 
>     Gunnar Hellström
>     GHAccess
>     gunnar.hellstrom@ghaccess.se <mailto:gunnar.hellstrom@ghaccess.se>
>
>     _______________________________________________
>     Audio/Video Transport Core Maintenance
>     avt@ietf.org <mailto:avt@ietf.org>
>     https://www.ietf.org/mailman/listinfo/avt
>     <https://www.ietf.org/mailman/listinfo/avt>
>
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se