Re: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-16.txt

[Tim Bruylants <[e-mail]>]

Following this comment by Stephan Wenger, we changed the "transmode" parameter from required to optional and provided a default behavior when not specified. We modified the "packetmode" parameter from optional to required because no neutral default behavior is favorable.

Tim.

-----Original Message-----
From: Stephan Wenger <[e-mail]> 
Sent: Wednesday 16 June 2021 17:37
To: Tim Bruylants <[e-mail]>; Thomas Richter <[e-mail]>; [e-mail]
Subject: Re: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-16.txt

Not having skin in this game, but historically most RTP payload formats try to minimize the number of required parameters and instead specify default values in case a parameter is not included.  That keeps the SDP small while still allowing for the necessary flexibility.  And, it avoids unnecessary discussions motivated by unnecessary IPR.
S.


On 6/16/21, 04:14, "avt on behalf of Tim Bruylants" <[e-mail] on behalf of [e-mail]> wrote:

    Hi Thomas,

    I will move this parameter un line up into the "required" parameters in the next draft version that I prepared. I'm still waiting for potential reviewers comments, so I'll issue the update after the IESG Telechat ends (so somewhere tomorrow). It won't change the way that our RTP draft works, so I guess (and hope) that this is an acceptable change.

    Tim

    -----Original Message-----
    From: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=XCJoW-7jJ_X3EhNCjNm4AyEnQ7DCBV4F-AZfVv0D0Iw&s=DXrCmA3CuekbjAt6Njw7Q2nSSmbI6WvdFhSTGJOJEp4&e=> 
    Sent: Wednesday 16 June 2021 12:19
    To: Tim Bruylants <[e-mail]>; [e-mail]
    Subject: Re: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-16.txt



    Am 16.06.2021 um 12:09 schrieb Tim Bruylants:
    > Hi Thomas,
    > 
    > I don't know. It does not impact the text itself, but it does impact some implementations that might already exist. The document is currently (actually today) under review at the IESG Telechat, so I'm expecting some feedback there. But I'm not sure if we can still change this (or not).
    > 
    > What is the issue with this parameter being optional? SDP enables you to specify the parameter when negotiating, so implementations that need to can always specify it. I'm probably missing a use-case here.

    The use case is that a decoder does not need to guess what type of a stream is coming, even in case it supports both types. This may result in a quicker setup time. IOWs, there is no stream analysis needed. In case the first attempt at the transport type is incorrect, this may loose a frame.

    Greetings,
    	Thomas

    _______________________________________________
    Audio/Video Transport Core Maintenance
    [e-mail]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_avt&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=XCJoW-7jJ_X3EhNCjNm4AyEnQ7DCBV4F-AZfVv0D0Iw&s=S7kZM4PBD7ffiw9t-EVeNHhJ370TY6Ms8KVke-5Ex5o&e=