[media-types] Re: [IANA #1420197] application/vnd.pp .systemverify+xml registration request

There is no required place to publish the XSD.  It can be put anywhere that is expected to be a stable location.  Adding a link to the XSD in the registration in the section for the published specification would be ideal.

Thanks,

Darrel
________________________________
From: Amanda Baber via RT <[email protected]>
Sent: Wednesday, June 18, 2025 1:59 PM
Cc: [email protected] <[email protected]>; Darrel Miller <[email protected]>
Subject: [IANA #1420197] application/vnd.pp.systemverify+xml registration request

Hi Darrel,

Resending this update from June 10th.

In light of this, is there a way they should update their media type form?

thanks,
Amanda

On Tue Jun 10 23:01:13 2025, sabrina.tanamal wrote:
> Hi Darrel,
>
> We have a response from the applicant:
>
> The most basic XSD for this is this one:
>
> <?xml version="1.0" encoding="utf-8"?>
> <xs:schema attributeFormDefault="unqualified"
> elementFormDefault="qualified"
> targetNamespace="https://pepperpot.media/2025/systemverify"
> xmlns:xs="http://www.w3.org/2001/XMLSchema">
> <xs:element name="SystemVerify">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="Title" type="xs:string" />
> <xs:element name="Description" type="xs:string" />
> <xs:any processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> </xs:schema>
>
> I am happy to host the XSD under the https://pepperpot.media site, is
> there an expected place to publish it?
>
> An example file that complies with the XSD is this one:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <SystemVerify xmlns="https://pepperpot.media/2025/systemverify"
> xmlns:w="https://pepperpot.media/2025/systemverify/windows">
> <Title>Patricia Requirements</Title>
> <Description>The following programs and drivers need to be installed
> for Patricia to work.</Description>
> <w:Windows>
> <w:Programs>
> <w:Program>
> <w:Title>Firefox</w:Title>
> <w:Description>You need the Firefox browser installed via an EXE or
> MSI file downloaded from the Firefox download site.</w:Description>
> <w:RegistryLocal>
> <w:DisplayNamePrefix>Mozilla Firefox</w:DisplayNamePrefix>
> <w:VersionMinimum>200.0</w:VersionMinimum>
> </w:RegistryLocal>
> </w:Program>
> <w:Program>
> <w:Title>Redwax SignText</w:Title>
> <w:Description>You need the Redwax SignText native browser extension
> installed via an MSI file.</w:Description>
> <w:MSI>
> <w:ProductCode>{18187B9C-05E8-4BD3-87C3-2399CC8F2808}</w:ProductCode>
> <w:VersionMinimum>1.0</w:VersionMinimum>
> </w:MSI>
> </w:Program>
> <w:Program>
> <w:Title>MPEG2 Video Extension</w:Title>
> <w:Description>The MPEG2 Video extension is installed from a MSIX
> package.</w:Description>
> <w:Package>
> <w:Name>Microsoft.MPEG2VideoExtension</w:Name>
> <w:VersionMinimum>2.0</w:VersionMinimum>
> </w:Package>
> </w:Program>
> </w:Programs>
> <w:Drivers>
> <w:Driver>
> <w:Title>Aventra MyEID</w:Title>
> <w:Description>You need the Aventra MyEID driver downloaded from the
> Aventra download site, with a mininum version of
> 2.3.0.</w:Description>
> <w:DriverName>Red Hat VirtIO Ethernet Adapter</w:DriverName>
> <w:Provider>Red Hat, Inc.</w:Provider>
> <w:VersionMinimum>100.0</w:VersionMinimum>
> </w:Driver>
> </w:Drivers>
> </w:Windows>
> </SystemVerify>
>
> The vast majority of data is under the Windows tag, which is under its
> own namespace. The idea is that the Windows element can be expanded
> without baking the format just yet. If you look closely there are
> three different ways a program might be installed on windows, and more
> ways are likely to appear in future. The format will have to adapt as
> new capabilities are added.
>
> In future there will be a Linux tag under it's own namespace, and so
> on.
>
> The goal is that I give you a file, and you open this file the same
> way you would open a PDF. This file is loaded by the System Verify
> application which gives you this:
>  PastedGraphic-1.png
> Image not shown because display is disabled in system configuration.
>
> The end goal is not to set up your machine correctly, lots of tools
> exist to do that. Instead, the end goal is for the long suffering end
> user who has had IT back and forth 100 times to say their machine is
> fine but their machine isn't fine and they can't get their work done
> to go "look, big red X, no idea what the big red X means but make it
> go away".
>
> At the same time, the long suffering IT person has an independent
> machine readable file that describes the requirements of whatever
> system is being installed. At a glance, they can see which tiny detail
> has been missed, with no drama, and can sort it out in no time at all.
>
> ====
>
> Thanks,
> Sabrina (filling in for Amanda)
>
> On Fri Jun 06 02:56:51 2025, [email protected] wrote:
> > > Published specification: The format will be described by an XSD.
> >
> > Could the XSD be linked to in this registration?  If not, will there
> > be a URL in the content that can be dereferenced to access the XSD
> > e.g. schemaLocation? If yes, how would someone creating a
> > "systemverify" document know that they have to provide a
> > schemaLocaltion?
> >
> > I'm just trying to make sure that there is some way to discover this
> > XSD.
> >
> > Darrel
> > ________________________________
> > From: Amanda Baber via RT <[email protected]>
> > Sent: Monday, June 2, 2025 12:23 PM
> > Cc: Darrel Miller <[email protected]>; [email protected] <media-
> > [email protected]>
> > Subject: [IANA #1420197] application/vnd.pp.systemverify+xml
> > registration request
> >
> > Hi Darrel,
> >
> > Can you review this one by June 16th?
> >
> > thanks,
> > Amanda
> >
> > =====
> >
> > Name: Graham Leggett
> >
> > Email: [email protected]
> >
> > Media type name: application
> >
> > Media subtype name: vnd.pp.systemverify+xml
> >
> > Required parameters: N/A
> >
> > Optional parameters: N/A
> >
> > Encoding considerations: binary
> >
> > Security considerations: The systemverify format describes the
> > requirements of a
> > software system, and contains no active elements or
> > elements by reference. The intention is to support XML
> > signatures so that the entity publishing the requirements
> > can be strongly identified. As an XML format, security
> > considerations described by RFC7303 section 10 apply.
> >
> > Interoperability considerations: The XML in the format is namespaced
> > to allow future
> > extension of the format.
> >
> > Published specification: The format will be described by an XSD.
> >
> > Applications which use this media: System Verify application, a tool
> > that can compare a defined set of requirements with what is actually
> > installed.
> >
> > Fragment identifier considerations: Fragments would be handled as per
> > XHTML.
> >
> > Restrictions on usage: None.
> >
> > Provisional registration? (standards tree only): No
> >
> > Additional information:
> >
> > 1. Deprecated alias names for this type: none
> > 2. Magic number(s): none
> > 3. File extension(s): systemverify
> > 4. Macintosh file type code: none
> > 5. Object Identifiers: none
> >
> > General Comments:
> >
> > Person to contact for further information:
> >
> > 1. Name: Graham Leggett
> > 2. Email: [email protected]
> >
> > Intended usage: COMMON
> >
> > Used as a document format that can describe the requirements of
> > a software system. This can be used by tools that compare the
> > requirements of a system to what is actually installed.
> >
> > Author/Change controller: Graham Leggett

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