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

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

On Mon, May 3, 2021 at 7:57 AM Tim Bruylants <[e-mail]> 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.

-MSK