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

[Spencer Dawkins at IETF <[e-mail]>]

I apologize for asking, but ...

On Tue, May 18, 2021 at 4:43 PM Gunnar Hellström <
[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
> > 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
> ....
> > 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..

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