[media-types] Re: [IANA #1443219] application/aas+zip registration request
Alexey Melnikov <[email protected]>
| Newsgroups | gmane.ietf.types |
|---|---|
| Message-ID | <[email protected]> |
Hi Amanda, On 20/02/2026 01:39, Amanda Baber via RT wrote: > Hi Alexey, > > They write, "The correct one is 'aas+zip.' Since we will also want to register the other two MIME types, 'aas+json' and 'aas+xml,' it would be best to use this format to maintain consistency." > > Can we register this now, or do they need to update the spec first? Please ask them when they can update the specification. But Ok to register now. Best Regards, Alexey > > thanks, > Amanda > > On Wed Feb 18 18:09:52 2026, [email protected] wrote: >> Hi Amanda, >> >> On 05/02/2026 20:29, Amanda Baber via RT wrote: >>> Hi Alexey, >>> >>> Would you be able to review this for us by February 19th? The IESG >>> just approved the organization for standards-tree registration. >>> >>> thanks, >>> Amanda >>> >>> ===== >>> >>> Name: Sandeep Rudra >>> >>> Email:[email protected] >>> >>> Media type name: application >>> >>> Media subtype name: aas+zip >> Can I ask for clarification about the media type name. >> >> The referenced specification >> <https://industrialdigitaltwin.io/aas-specifications/IDTA- >> 01005/v3.1/aasx.html> >> lists: >> >> application/asset-administration-shell-package >> >> >> Which one of the two is correct? >> >> Other than the above, I don't see a problem with this registration. >> >>> Required parameters: N/A >>> >>> Optional parameters: N/A >>> >>> Encoding considerations: binary >>> >>> Security considerations: This media type is a package container based >>> on ZIP and may contain multiple embedded files and resources. >>> >>> Receivers MUST treat the entire package as untrusted input. >>> >>> Implementations SHOULD protect against decompression bombs (ZIP >>> bombs) by enforcing limits on: >>> >>> - Total uncompressed size >>> - Number of entries >>> - Compression ratio >>> - Any recursion/nesting behavior used by tooling >>> >>> Implementations that extract files MUST prevent path traversal by >>> rejecting entries with absolute paths, drive letters, or “..” >>> segments, and SHOULD avoid overwriting existing files without >>> explicit policy. >>> >>> Since the container can embed arbitrary content, applications SHOULD >>> validate embedded content types before processing. >>> >>> Confidentiality, integrity, and authenticity are not provided by the >>> container itself; use TLS for transport security and use signatures >>> if tamper protection or provenance is required. >>> >>> Interoperability considerations: The package structure, >>> relationships, and mandatory parts are defined by the specifications >>> of Industrial Digital Twin Association e.V. >>> >>> Interoperability requires following the defined folder and >>> relationship model and honoring the internal content type >>> declarations. >>> >>> Producers SHOULD avoid proprietary extensions unless they are clearly >>> documented and safely ignorable by consumers. >>> >>> Published specification: IDTA AAS Specification Part 5 — AASX Package >>> File Format (https://industrialdigitaltwin.org/en/content- >>> hub/aasspecifications) >>> >>> Applications which use this media: Used for exchanging complete >>> interoperable digital twin models as a single package file for >>> upload/download, storage, and partner exchange in industrial digital >>> twin scenarios. >>> >>> Fragment identifier considerations: Not defined for this media type. >>> >>> Restrictions on usage: None >>> >>> Provisional registration? (standards tree only): No >>> >>> Additional information: >>> >>> 1. Deprecated alias names for this type: N/A >>> 2. Magic number(s): N/A >>> 3. File extension(s): aasx >>> 4. Macintosh file type code: N/A >>> 5. Object Identifiers: N/A >>> >>> General Comments: The content serves for the exchange of >>> interoperable digital twin model information by the specifications of >>> the AAS (Asset Administration Shell). The package format goes by AASX >>> (serialized and zipped file information). >>> >>> Person to contact for further information: >>> >>> 1. Name: Sandeep Rudra >>> 2. Email:[email protected] >>> >>> Intended usage: COMMON >>> >>> Author/Change controller: Industrial Digital Twin Association e.V. >>> ([email protected]) >>> > _______________________________________________ > media-types mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ media-types mailing list -- [email protected] To unsubscribe send an email to [email protected]