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

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Tue, 18 May 2021 13:34:41 -0700

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
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/

----------------------------------------------------------------------
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

1. -----

FP: Please expand acronyms (CSRC, SDP, BOM, PSTN,...) on first use.

2. -----

      Since
      simultaneous typing by more than two parties is very rare, this
      method can be used successfully with good performance.  Recovery

FP: I had question on this point, i.e. how was it evaluated that simultaneous
typing by more than two parties is very rare, but that was answered in section
1.3 Intended application - so I would suggest adding a forward reference to
that section in the paragraph quoted above.

3. -----

   text stream using the RTP-mixer method.  The capability is indicated
   by use of an SDP media attribute "rtt-mixer".

FP: Please add a reference to RFC 8866.

4. -----

   streams in text format.  This is especially true if support of un-
   encrypted SIP and media is supported because of lack of such support
   in the target endpoints.  However, the mixing for conference-aware

FP: I have a problem parsing this sentence "... if support ... is supported
because of lack of such support"

5. -----

   is the timestamp of packet 102 THAT was received.  So B1 does not

FP: nit - all capitals THAT.

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?

7. -----

    |                                              | |
    |(mix)[Bob)] Bob as well.                       | |

FP: one space character too much

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 18 May 2021 23:42:42 +0200

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.

> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
....
> 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 
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
[email-masked]

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 19 May 2021 08:48:06 -0500

I apologize for asking, but ...

On Tue, May 18, 2021 at 4:43 PM Gunnar Hellström <
[email-masked]> wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

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..

Best,

Spencer

---

From: Francesca Palombini <[email-masked]>
Date: Wed, 19 May 2021 13:58:22 +0000

Hi,

Spencer: thanks for putting into words what my uneasiness with the current text was. Rephrasing in that way would address my point.

Otherwise yes, I believe some text would be necessary to clarify that the MUST is really about “parsing and understanding the control code”, in order to ignore unsupported ones.

Francesca

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wednesday, 19 May 2021 at 15:48
To: Gunnar Hellström <[email-masked]>
Cc: Francesca Palombini <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, IETF AVTCore WG <[email-masked]>
Subject: Re: [AVTCORE] Francesca Palombini's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT)

On Tue, May 18, 2021 at 4:43 PM Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:
Francesca,

....

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..

Best,

Spencer

Regards

Gunnar

> [email-masked]<mailto:[email-masked]>

--
Gunnar Hellström
GHAccess
[email-masked]<mailto:[email-masked]>

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avt

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 19 May 2021 21:35:24 +0200

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:
> On Tue, May 18, 2021 at 4:43 PM Gunnar Hellström 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Francesca,
>
>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>     <https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/>
>     >
>     >
>     >
>     >
> 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.
>
> 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

>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/avt>
>
>     -- 
>     Gunnar Hellström
>     GHAccess
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/avt>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 25 May 2021 21:38:43 +0200

Francesca,

I am preparing a new version, with actions on your comments.

> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
[GH] Done
> that section in the paragraph quoted above.
[GH] Accepted.
> FP: Please add a reference to RFC 8866.
[GH] Accepted
> because of lack of such support"
[GH] Simplified wording applied
> FP: nit - all capitals THAT.
[GH]Changed to lower case.
> Maybe this does not need to be a BCP 14 MUST?
[GH] Changed as adviced by Spencer Dawkins and agreed by Francesca.
> FP: one space character too much
[GH] Done

Thanks,

Gunnar