[media-types] [IANA #1451788] application/vnd.maxar. archive.3tz+zip registration request

Hi Alexey,

Sending a reminder for this modification request from May 9th.

thanks,
Amanda

On Sat May 09 03:07:36 2026, amanda.baber wrote:
> Hi Alexey,
> 
> Would you be able to review this request to modify
> application/vnd.maxar.archive.3tz+zip by May 22nd?
> 
> Multiple sources confirm that the original change controller (Maxar)
> has been rebranded as Vantor, and I can confirm the old domain
> redirects to the new one. The confirmation request I sent to the
> original contact hasn't bounced yet (I understand it might not), but
> LinkedIn appears to confirm, as the submitter reports, that he's moved
> on to another company, so we believe that it's OK to process this. If
> this were only a contact/controller change, we would have made the
> changes without expert review, but there are a few other changes. This
> is the submitter's summary:
> 
> ==
> 
> The main changes apart from company name is:
> 
> PoC changed from Erik Dahlström to me, since Erik left the company.
> The links to the specifications:
> 3D Tiles specification relinked towards the official Open Geospatial
> Consortium approved version
> The 3TZ specification relinked from the Erik’s private GitHub page to
> the 3TZ specification on official Maxar GitHub page
> An addition file extension `.3dtiles.zip
> Some additional wording around security
> 
> ==
> 
> You can find the original here:
> 
> https://www.iana.org/assignments/media-
> types/application/vnd.maxar.archive.3tz+zip
> 
> thanks,
> Amanda
> 
> =====
> 
> Name: Björn Blissing
> 
> Email: [email protected]
> 
> Media type name: application
> 
> Media subtype name: vnd.maxar.archive.3tz+zip
> 
> Required parameters: N/A
> 
> Optional parameters: N/A
> 
> Encoding considerations: binary
> 
> 3tz container files are binary ZIP-based container files encoded using
> the application/zip media type.
> 
> Security considerations: This media type employs a specific profile of
> the application/zip format, so the security considerations that apply
> to application/zip and the +zip structured syntax suffix also apply to
> 3tz container files. All processors that read 3tz container files
> should rigorously check the size and validity of data retrieved,
> including ZIP structures, entry sizes, checksums, and offsets.
> 
> The 3tz container format does not itself define active or executable
> content. However, 3tz container files may embed content that has its
> own security implications when parsed, rendered, or otherwise
> processed.
> 
> Processors should guard against decompression bombs and other
> resource-exhaustion attacks arising from malformed or highly
> compressed ZIP entries, including entries compressed with DEFLATE or
> Zstandard. Processors that extract files from the container should
> validate file paths and reject absolute paths, parent-directory
> traversal sequences, and other filenames that would escape the
> intended extraction root.
> 
> The archive must contain at the root level a file named tileset.json.
> The security considerations for JSON described in RFC 8259, Section
> 12, and for 3D Tiles content apply to this file. The format of this
> file is specified in:
> 
> https://docs.ogc.org/cs/22-025r4/22-025r4.html
> 
> The format recommends relative references inside the archive, but
> referenced resources may in some cases be external to the archive.
> Implementations should treat dereferencing external resources with
> appropriate caution.
> 
> In addition, because of the various content types that can be embedded
> in 3tz container files, application/vnd.maxar.archive.3tz+zip may
> describe content that poses security implications beyond those noted
> here. However, only in cases where the processor recognizes and
> processes the additional content, or where further processing of that
> content is dispatched to other processors, would security issues
> potentially arise. In such cases, matters of security would fall
> outside the domain of this registration document.
> 
> This media type does not itself provide confidentiality or strong
> integrity protection. If such protection is desired, it needs to be
> provided by external mechanisms such as HTTPS or digital signatures.
> 
> Interoperability considerations: N/A
> 
> Published specification: The 3D Tiles Archive Format v1.4
> specification is published at:
> 
> https://github.com/Maxar-Public/3tz-
> specification/blob/v1.4/Specification.md
> 
> Applications which use this media: This media type is used for the
> distribution of large 3D Tiles datasets. The following list of
> applications is not exhaustive.
> 
> * Vantor 3D Explorer
> * Vantor Construct
> 
> Fragment identifier considerations: No fragment identifier syntax is
> defined for this media type. As this media type uses the +zip
> structured syntax suffix, fragment identifier considerations are as
> specified for +zip in RFC 6839.
> 
> Restrictions on usage: N/A
> 
> Provisional registration? (standards tree only): No
> 
> Additional information:
> 
> 1. Deprecated alias names for this type: N/A
> 2. Magic number(s): 0: PK 0x03 0x04
> 3. File extension(s): .3tz, .3dtiles.zip
> 4. Macintosh file type code: ZIP
> 5. Object Identifiers: N/A
> 
> General Comments: The 3D Tiles Archive Format (3tz) is a container
> format based on the ZIP file format. It is used to encapsulate large
> 3D Tiles datasets and their associated files.
> 
> Person to contact for further information:
> 
> 1. Name: Björn Blissing
> 2. Email: [email protected]
> 
> Intended usage: COMMON
> 
> Author/Change controller: The published specification is a work
> product of Vantor Inc. Vantor Inc. has change control over this
> specification.

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]