Re: [AVTCORE] AD review of draft-ietf-avtcore-multi-party-rtt-mix

["Murray S. Kucherawy" <[e-mail]>]

On Fri, Apr 9, 2021 at 2:47 AM Gunnar Hellström <
[e-mail]> wrote:

> -On including RFC8174 in a group reference to BCP 14:
>
> I think RFC 8174 is a good clarification for use of "SHOULD" and "should"
> etc., but I failed to create the proper reference to BCP 14 in xml for
> xml2rfc v.3.
> There are various instructions and examples available, but I cannot make
> them work in practice.
> Temporarily I copied the way that draft-ietf-avtcore-rtp-vvc-08 handles
> it, by just mentioning BCP 14 in text in the boilerplate and not include it
> in the reference list.
> Do you know a good xml template for the BCP 14 boilerplate?
>
It appears to be common to just include normative references to RFC 8174
and RFC 2119.

> -On review of SHOULD etc. in sections 3 and 4.
>
> Do you mean that I shall review the use of the RFC 2119 words in sections
> 3 and 4 and judge if I can use the SHALL/MUST wording, and if I want to
> keep SHOULD, then insert advice for decision of when to follow the advice.
>
> A possibility is to have SHOULD only in the introduction in 4.2 and then
> SHALL in the rest of 4.2.x because it is only applicable for
> implementations selecting to implement the procedures introduced in 4.2.
>
Generally I believe SHOULD provides an implementer with a choice.  Clearly
that choice is weighted (unlike MAY), but still when the reader is left
with a choice but doesn't know how to make it, the document may actually be
making things worse.  Thus my advice is to say something of the form "you
SHOULD do X, unless Y".

> The current wording in 4.2 is:
>
> "4.2.  Multi-party mixing for multi-party unaware endpoints
>
>    When the mixer has indicated RTT multi-party capability in an SDP
>    negotiation, but the multi-party capability negotiation fails with an
>    endpoint, then the agreed "text/red" or "text/t140" format SHALL be
>    used and the mixer SHOULD compose a best-effort presentation of
>    multi-party real-time text in one stream intended to be presented by
>    an endpoint with no multi-party awareness."
>
> Could it be sufficient to use SHALL in most places in all 4.2.x sections
> and change the beginning of 4.2 to:
>
> "4.2.  Multi-party mixing for multi-party unaware endpoints
>
>    When the mixer has indicated RTT multi-party capability in an SDP
>    negotiation, but the multi-party capability negotiation fails with an
>    endpoint, then the agreed "text/red" or "text/t140" format SHALL be
>    used and the mixer SHOULD compose a best-effort presentation of
>    multi-party real-time text in one stream intended to be presented by
>    an endpoint with no multi-party awareness,* when that is desired in
> the actual implementation. The following specifies a procedure for that
> situation"*
>
> - and then mainly use SHALL in the rest of section 4.2.
>

Yes, that's a definite improvement.  The other alternative is to avoid the
ambiguous use of SHOULD, such as:

"When the mixer has indicated RTT multi-party capability in an SDP
negotiation, but the multi-party capability negotiation fails with an
endpoint, then the agreed "text/red" or "text/140" format SHALL be used and
the mixer will then typically compose a best-effort presentation of
multi-party real-time text in one stream intended to be presented by an
endpoint with no multi-party awareness."

Here you would avoid use of SHOULD altogether, which is something to
consider if the thing you're describing has nothing to do with
interoperability between components anyway.

-MSK