[media-types] [IANA #1418198] application/vnd.angel. evidence-package registration request
"Amanda Baber via RT" <[email protected]>
| Newsgroups | gmane.ietf.types |
|---|---|
| Message-ID | <[email protected]> |
Hi Murray, More information from the requester: "I'm still getting my head around the I-D process -- I'm currently submitting the draft for the independent stream (which seemed to make sense to me as I have no affiliation with any larger organisation that might have some power to influence!). If the media type can be assigned to the standards tree based on this, as far as I am concerned this is the best option, after all Eden and I designed the format to be as useful as possible for a wider audience! I wonder, if this is the case, something like application/evidence-package might be more suitable (i.e. also dropping the "angel." which is the name of the suite of tools containing an implementation of the format)." They also asked for information about how to submit the I-D for inclusion in the IETF stream. Should they be directed to a particular working group? In the past, a few standards-tree media type registrations were made via independent stream RFCs. Nevil, I think, coordinated the separate IESG approval process (for the type itself) with us around the time of the conflict review. It's been several years since we've seen one of those, though. thanks, Amanda On Mon May 19 19:53:19 2025, [email protected] wrote: > On Wed, May 7, 2025 at 6:36 PM Amanda Baber via RT < > [email protected]> wrote: > > > > > The requester adds, "I intend to publish a formal format > > > > specification > > on > > > > the same GitHub repository (lilopkins/evidenceangel) soon." > > > > > > > > > > What's the timeline on such publication? I'm tempted to suggest > > > holding > > a > > > final decision until we can see that. > > > > The timeline for format publication is likely within a week or so. I > > do > > intend to publish this as an RFC once I have worked out a few of the > > finer > > details, and am happy to wait for the media type allocation until > > this is > > handled if that is preferred. > > > > I see that this has been published, apparently with intent to seek > publication as an RFC. If that's being done in the IETF stream, this > becomes eligible for a place on the standards tree. Do we want to > proceed > with a vendor tree registration or just leave it to the publication of > that > document? > > > > > > ===== > > > > > > > > Name: Lily Hopkins > > > > > > > > Email: [email protected] > > > > > > > > Media type name: application > > > > > > > > Media subtype name: vnd.angel.evidence-package > > > > > > > > Required parameters: N/A > > > > > > > > Optional parameters: N/A > > > > > > > > Encoding considerations: binary > > > > > > > > Security considerations: This type can store arbitrary files and > > > > data > > > > within it. These files are never executed and must only be > > > > expanded > > from > > > > the format. Potentially, data might be handled in other manners > > > > when > > > > exported to another format, this should be handled by the > > > > exporting > > code. > > > > > > > > Interoperability considerations: The format is based upon the > > > > application/zip format, with specific internal structure. Other > > software > > > > could implement specific ways to handle this format, or may just > > handle it > > > > as an application/zip file. Software that implements this format > > > > should > > > > expect that it may have invalid internal data, and should handle > > > > this > > > > reasonably. > > > > > > > > As such, this format can interoperate similarly to > > > > application/zip. > > > > > > > > > > Are there any prior versions of this media type out in the wild? > > > > > > Are there any concerns with interoperation across platforms or > > > particular > > > transports? > > > > The current scope of this format is very limited to the best of my > > knowledge, and data has not been shared beyond a small group of about > > 5 > > testers. There has been a previous version, however the change > > introduced a > > new field and this is backwards compatible. > > > > OK. > > > > There are no concerns for interoperation in the context of platforms > > or > > transports. > > > > Please say this as part of "Interoperability considerations". > > -MSK _______________________________________________ media-types mailing list -- [email protected] To unsubscribe send an email to [email protected]