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

[Gunnar Hellström <[e-mail]>]

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 
> <[e-mail] <mailto:[e-mail]>> 
> 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
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/avt
>     <https://www.ietf.org/mailman/listinfo/avt>
>
>     -- 
>     Gunnar Hellström
>     GHAccess
>     [e-mail] <mailto:[e-mail]>
>
>     _______________________________________________
>     Audio/Video Transport Core Maintenance
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/avt
>     <https://www.ietf.org/mailman/listinfo/avt>
>
-- 
Gunnar Hellström
GHAccess
[e-mail]