Re: [rtcweb] Robert Wilton's No Objection on draft-uberti-rtcweb-rfc8829bis-03: (with COMMENT)

[Justin Uberti <[e-mail]>]

On Mon, Oct 3, 2022 at 9:58 AM Robert Wilton via Datatracker <
[e-mail]> wrote:

> Robert Wilton has entered the following ballot position for
> draft-uberti-rtcweb-rfc8829bis-03: 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-uberti-rtcweb-rfc8829bis/
>
>
> Thank you for your comments, and apologies for the late response. See
> inline:



>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Hi,
>
> Thanks for this easy to review diff.
>
> (1) p 23, sec 4.1.1.  Constructor
>
>    [RFC8829] defined a policy known as "max-bundle", which, while
>    defined identically to the "must-bundle" policy described above, was
>    implemented by some implementations according to an earlier, pre-
>    standard definition (in which, for example, no "m=" sections were
>    marked as bundle-only).  As a result, "max-bundle" is considered
>    deprecated, and new applications should use the "must-bundle" policy
>    instead.
>
> Disclaimer, I don't know this protocol.
>
> I'm not sure why this isn't 'must use the "must-bundle" policy instead of
> "max-bundle."'
>
>
As noted in a separate reply, this particular guidance is for JSEP
applications, not JSEP implementations, and as a result is not intended to
be normative.


> It is somewhat unclear to me how implementations move from RFC8829 to this
> RFC.
>  Specifically, it is unclear, for implementations that follow this RFC
> rather
> than RFC8829 (which is being obsoleted by this RFC), what, if any,
> handling of
> "max-bundle" is permitted.  My interpretation is that the "max-bundle"
> policy
> can still be specified, but its behaviour is not well-defined.  Further,
> is it
> appropriate for new implementations to also support "max-bundle" and treat
> it
> identically to "must-bundle", or should they reject that policy?
>
> In summary, I think that some extra explanation here might be helpful.
>

For existing JSEP implementations, I think the typical behavior will be to
support both must-bundle and max-bundle until JSEP applications have
largely stopped using max-bundle (as to do otherwise might break them). At
that point, silently ignoring the request to use max-bundle is probably the
safest solution (vs trying to remap it to must-bundle). New implementations
will have to make a similar decision of whether they should support
max-bundle to deal with legacy applications.

WebRTC has always had to consider how to sunset pre-standard behavior, and
so this particular case should be pretty typical. So I tend to think we
don't need much new text here, although I could be persuaded to say that
"requests for "max-bundle" must be ignored", or something to that effect.

Justin