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

Gunnar Hellström <> Tue, 18 May 2021 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B73E73A104E; Tue, 18 May 2021 14:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MhH3Uuwk4CuC; Tue, 18 May 2021 14:42:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71E2B3A104D; Tue, 18 May 2021 14:42:47 -0700 (PDT)
Received: from [] ( []) (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: by (Postfix) with ESMTPSA id 33DD320CB9; Tue, 18 May 2021 23:42:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1621374164; bh=pP8rkkKMXH6vcu1fpXZriu38jrk2cDmarIy7lliId2c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=rRucE468RrOc3HNr96fFiZn8shz4qcVwOSBCVHInm4kzrSHftOZBBYCDUfSKnJ6NN eKUXvJubmsYosOCqfnE7Uo8W39GJI6dUVxHGv3JgcsLOGeBhcPT2zmGN6ra73jyZmS p/Cmt72anhsJ6pKwCUsG4h/PO2IQ1icDcOL0+qLQ=
To: Francesca Palombini <>, The IESG <>
References: <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Tue, 18 May 2021 23:42:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: <>
Subject: Re: [AVTCORE] Francesca Palombini's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 May 2021 21:42:53 -0000


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
> for more information about DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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?

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 

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?



> _______________________________________________
> Audio/Video Transport Core Maintenance

Gunnar Hellström