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

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

Hi Darrel, Alexey,

Some years ago, we were asked to list standards-tree media types in the provisional registry while the request is being reviewed. Once the reviewer approves them, we remove them from that registry. (The registry also lists types that we were asked to list only in the provisional registry until they were ready to submit a request for permanent registration.)

Alexey would have to answer the question about whether the text of a registration request must be included in the specification (I suspect that it doesn't).

thanks,
Amanda

On Sun May 28 20:01:53 2023, [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]>
> Sent: Monday, May 15, 2023 8:05:02 PM
> Cc: Darrel Miller <[e-mail]>; [e-mail] <media-
> [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]
> 
> 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]
> 
> Intended usage: COMMON
> 
> Author/Change controller: ITU-T & ISO/IEC JTC 1
> RT Version 5.0.3