Re: [AVTCORE] AD Review of draft-ietf-payload-rtp-jpegxs-11

"Murray S. Kucherawy" <> Mon, 03 May 2021 16:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 518BB3A1C47 for <>; Mon, 3 May 2021 09:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TvQNuNqmc01I for <>; Mon, 3 May 2021 09:58:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F5423A1CAF for <>; Mon, 3 May 2021 09:58:11 -0700 (PDT)
Received: by with SMTP id k19so3307183vsg.0 for <>; Mon, 03 May 2021 09:58:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n1scRnvaiqJj3yznxjmLgXF/cor2YWm/OM92we5c7jY=; b=U5L9V5CkyXnYfNahTw2qYDP7AfPuAS5OR2nsxsrgn2bwxcKiqpL/hM7HomYMFqA+/T pVtT8w3U1QOWeY/P4ghdKtE5YT84l2pCcjLJ/yrB8ne2+8FliQP1/FZX7N73C3Z4JBue xHn+Wdn7O59dH+3JdNm/aAemmdSV/nq60WhXcMiYa6h4KQE8gf8uAjX0Ki0P8kDTRJIh TnEn7wYoYJu7R5B32kEsgWcoVF6+O29ZVj/zZc/CafbAwpJBu5ykvSB48Pewi78QAZBH 9jULhG0ym1rpXpOLFJkD+7TYlkgjDTzNvQnR4harMeT4xzzLpemL6c4PkbiGjkON1lUE ifWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n1scRnvaiqJj3yznxjmLgXF/cor2YWm/OM92we5c7jY=; b=EEdVto3Z/YNxaCIgW8JnU4g2fy1ImeTlWEU+YhjWzv2HVlKKEAckFYjC65dKrR8dij b9j0p7wFOkrxub/dR59FgInGggCeb//q+wtfwvzHyAK40plBLj69RF8lk0km7YTKyKzF CB36dgEazkm7PTWVllL0Awc9RLNPYGo9rDelcC9J2QhMkOaooz3RqKgjliK2XpFRs6oP 5d+ockZD2y8dZyQBd5Xn8ahDyZ/bzSMV0ywJZKJ9sFzFIXDH9q2FQ+edbSFjS07kj5Qm dJx4yOS1UqgkNUHG6DFaoPOOhdLAwZh7RnZiR5mnLy09W5/UPH+GZZoo1g1GO8UCl2KI 4kwQ==
X-Gm-Message-State: AOAM533igaswQWhgNpxEG9KClbZIQQ/li63x/Vjs4aS391hGcBn239GK TOeWc8pa0RW5/x24E5dxEUEEbg2SPICtbUW97lM=
X-Google-Smtp-Source: ABdhPJwtgt3elqjm8R61w933Y0LqfjSa3fWOYruk7Veu2pV7CDV48YrlBr7TxkYy3v/SNlfPExmAGBjjh96u6ymlKOs=
X-Received: by 2002:a67:cc2:: with SMTP id 185mr17174061vsm.0.1620061089509; Mon, 03 May 2021 09:58:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <PR3P192MB0748D48268FFC24A1BBE1DC4AC5B9@PR3P192MB0748.EURP192.PROD.OUTLOOK.COM>
In-Reply-To: <PR3P192MB0748D48268FFC24A1BBE1DC4AC5B9@PR3P192MB0748.EURP192.PROD.OUTLOOK.COM>
From: "Murray S. Kucherawy" <>
Date: Mon, 3 May 2021 09:57:58 -0700
Message-ID: <>
To: Tim Bruylants <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000c1357c05c16fddaa"
Archived-At: <>
Subject: Re: [AVTCORE] AD Review of draft-ietf-payload-rtp-jpegxs-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 May 2021 16:58:27 -0000

On Mon, May 3, 2021 at 7:57 AM Tim Bruylants <> wrote:

> > Also in Section 2, the term "SOC Marker", though defined here, is not
> used below here.  Section 3.2 references the EOC Marker; should it
> reference both?
>   1) The term "SOC marker" is used in section 2 under "JPEG XS codestream
> header".
>   2) We clarified section 3.2, referencing "SOC marker".

Right, it was referenced in the Glossary that defines it, but not
elsewhere.  That seemed strange.

> > In Section 4.2, "As per specified" can just be "As specified".
> Alternatively, "As per RFC 3550, ..."  While I'm thinking about it, all
> these double references (e.g., "RFC 3550 [RFC3550]") throughout the
> document could be cleaned up.
>   We have cleaned up the "double references" throughout the text.

Thanks.  The RFC Editor would probably have done the same, but now your
AUTH48 might come a little sooner.

> The diagrams in Section 4.4 show (eventually) how the EOC marker fits
> into this, but not the SOC marker.  Should they?
>   We clarified that the SOC marker is part of the JPEG XS codestream
> header. The latter is clearly mentioned in the diagrams. Explicitly
> mentioning SOC in the diagrams would clutter the layout, and would probably
> require to explicitly add the other markers in the codestream header as
> well.

Fair enough.  In my layperson's reading of the work, it was odd that the
"end" marker was somehow worth mentioning explicitly but the "start" marker
was being taken for granted.

> > In Section 6.1, it's clear what a receiver would do with some of the
> optional parameters when they are absent (i.e., defaults are clear), but
> not in all cases.  What can a receiver safely assume about "depth",
> "width", or "height", for example, when not specified?
>   We thought this was clarified by section 6.2.1. Nevertheless, we added a
> short paragraph in section 6 (now section 7).
This could also be because I'm unfamiliar with the base work.  It might be
useful to mention in the registration that optional parameters are in fact
overrides to metadata within the payload, since I think that's what you're
telling me here.  But that's not a blocker for starting Last Call.

> Also on 6.1, this media type registration is missing required fields,
> including "Interoperability Considerations", "Published Specification",
> "Applications that use this media type", "Fragment identifier
> considerations", "Additional information" (which has four sub-fields",
> "Contact information", "Intended Usage", "Restrictions On Usage", "Author",
> and "Change Controller".  Please see RFC 6838.  Further, it would probably
> be a good idea to mention either in the registration or in the Security
> Considerations of this document that the payload being registered does not
> (or does) contain code that is executable.  The media type reviewers prefer
> people to be explicit on this point.
>   We have reworked the media type registration section to follow RFC 6838
> and RFC 4855.
>   We added the notion that the payload format and the JPEG XS encoding do
> NOT contain executable code (to the Security Considerations section).

Great, thanks!  I'll prepare the Last Call request now.