[media-types] [IANA #1272547] image/j2c registration request

[Amanda Baber via RT <[e-mail]>]

Hi Alexey,

Can you respond to this one?

thanks,
Amanda

On Mon May 29 13:59:46 2023, [e-mail] wrote:
> Hi Pierre,
> 
> My reading of RFC6838 here https://www.rfc-
> editor.org/rfc/rfc6838#section-3.1 is that you are registering this
> media type using a specification from a recognized standards-related
> organization (option 2).  The requirements are:
> 
> 
> > Standards-tree registrations from recognized standards-related
> organizations
> > are submitted directly to the IANA, where they will
> undergo Expert Review
> > [RFC5226<https://www.rfc-editor.org/rfc/rfc5226>] prior to approval.
> > In this case, the
> Expert Reviewer(s) will,
> > among other things, ensure that the required
> specification provides adequate
> > documentation.
> 
> The role of the Expert Review is to ensure that the format is
> sufficiently documented, and it is clear how the media type is to be
> used.  I am not aware of a requirement that the registration must be
> documented in the specification.   You do have the option of going
> back and updating RFC3745 https://www.rfc-editor.org/rfc/rfc3745 that
> contains all the media type registrations for JPEG 2000 related
> formats, however, I do not believe that is necessa
> 
> RFC6838 does say:
> 
> > The format MUST be described by a formal standards specification
> > produced
> > by the submitting standards-related organization.
> 
> However, I do not interpret that to mean the registration information
> must be described in the specification, only the details of the
> format.
> 
> @Alexey Melnikov<mailto:[e-mail]>,   Amanda,  Can you
> confirm my interpretation here?
> 
> Darrel
> 
> ________________________________
> From: Pierre-Anthony Lemieux <[e-mail]>
> 
> Hi Darrel and Amanda,
> 
> Isn’t there a requirement for the text of a registration request to be
> part of a published standard before the registration can be finalized?
> 
> The first edition of the standard (JPEG 2000) underlying the request
> was published in 2002, and was revised twice since then. None of these
> editions contained the text of the registration request below,
> however.
> 
> Best,
> 
> — Pierre
> 
> 
> 
> On Sun, May 28, 2023 at 13:01 Darrel Miller
> <[e-mail]<mailto:[e-mail]>> wrote:
> Amanda,
> 
> I have reviewed this submission and it looks good to me.  However, it
> is not clear to me why this is marked as provisional.  From what I can
> tell the standard was published in 2019.  It doesn't appear like this
> needs to be a provisional registration.
> 
> Darrel
> 
> ________________________________
> From: Amanda Baber via RT <[e-mail]<mailto:iana-
> [e-mail]>>
> Sent: Monday, May 15, 2023 8:05:02 PM
> Cc: Darrel Miller <[e-mail]<mailto:[e-mail]>>; media-
> [e-mail]<mailto:[e-mail]> <media-
> [e-mail]<mailto:[e-mail]>>
> Subject: [IANA #1272547] image/j2c registration request
> 
> Hi Darrel,
> 
> Can you review this new standards tree request by the 29th? Both of
> the organizations named in the change controller field are listed at
> https://www.iana.org/assignments/iesg-recognized-organizations.
> 
> thanks,
> Amanda
> 
> =====
> 
> Name: Pierre-Anthony Lemieux
> 
> Email: [e-mail]<mailto:[e-mail]>
> 
> Media type name: image
> 
> Media subtype name: j2c
> 
> Required parameters: N/A.
> 
> Optional parameters: N/A.
> 
> Encoding considerations: binary
> 
> Single JPEG 2000 codestream, whose structure is specified in Rec. ITU-
> T T.800 | ISO/IEC 15444-1.
> 
> Security considerations: JPEG 2000 codestreams contain structures of
> variable length and have an extensible syntax. Both of these aspects
> present potential security risks for implementations. In particular,
> variable length structures present buffer overflow risks and
> extensible syntax could result in the triggering of adverse actions.
> 
> Interoperability considerations: A JPEG 2000 codestream can use
> capabilities from any part of Rec. ITU-T T.8xx series | ISO/IEC 15444.
> The capabilities required to process the codestream are specified by a
> combination of the Rsiz parameter and the value of the CAP marker
> segment (see Rec. ITU-T T.800 | ISO/IEC 15444-1). In addition, a JPEG
> 2000 codestream does not contain information on the colourspace of the
> image. This information is implied or provided out-of-band.
> 
> Published specification: Rec. ITU-T T.8xx series | ISO/IEC 15444
> 
> Applications which use this media: Multimedia and scientific
> 
> Fragment identifier considerations: None
> 
> Restrictions on usage: None
> 
> Provisional registration? (standards tree only): Yes
> 
> Additional information:
> 
> 1. Deprecated alias names for this type: N/A
> 2. Magic number(s): Starts with the byte sequence: 0xFF 0x4F 0xFF 0x51
> 3. File extension(s): j2c, J2C, j2k, J2K
> 4. Macintosh file type code: N/A
> 5. Object Identifiers: N/A
> 
> General Comments: This media type refers to a data payload that
> consists of a single JPEG 2000 codestream that can contain
> capabilities from any part of ISO/IEC 15444. This data payload, and
> the file extensions "j2c" and "j2k" when the data payload is stored in
> a file, are in widespread use.
> 
> Person to contact for further information:
> 
> 1. Name: ISO/IEC JTC 1/SC 29/WG 1 Convenor
> 2. Email: [e-mail]<mailto:[e-mail]>
> 
> Intended usage: COMMON
> 
> Author/Change controller: ITU-T & ISO/IEC JTC 1
> RT Version 5.0.3