Re: [media-types] [IANA #1268784] application/prs.implied-document+xml registration request

[Alexey Melnikov <[e-mail]>]

Hi Amanda,

This is approved, but see my comments on the request #1, which apply to 
this one as well.

Best Regards,

Alexey


On 31/03/2023 15:25, Amanda Baber via RT wrote:
> Hi Alexey,
>
> The applicant sent an updated version of this third request that restores its missing fragment identifier considerations. Please see below.
>
> thanks,
> Amanda
>
> =====
>
> Name: Marek Čermák
>
> Email: [e-mail]
>
> Media type name: application
>
> Media subtype name: prs.implied-document+xml
>
> Required parameters: root: The local name of the root element in the XML document.
>
> Optional parameters: ns: The namespace URI of the root element, if specified.
> public: The PUBLIC identifier in the DTD, if provided.
> charset: The character set used by the document, with the same syntax and semantics as for application/xml [RFC 7303].
>
> Encoding considerations: binary
>
> Same as for application/xml [RFC 7303].
>
> Security considerations: Same as for application/xml [RFC 7303]. When processing this type, applications MUST ensure that the structure of the file matches "root", "ns" and "public", and if they intend to assign a more concrete media type to the file, they SHOULD verify that it is valid. Applications MUST NOT open files coming from untrusted sources if it could lead to arbitrary code execution.
>
> Interoperability considerations: Applications that accept or produce this type should not be assumed to have knowledge of more than the root element namespace and local name, and the PUBLIC identifier. It is not guaranteed that an application offering this type will produce a file in a format that is most commonly associated with parameters, and it is not guaranteed that an application accepting this type will be able to process it in any of the formats associated with the parameters.
>
> Published specification: N/A
>
> Applications which use this media: This media type is intended for applications that have to guess the media type of a file, but do not contain heuristics that allow to pick a more concrete media type with acceptable confidence.
>
> Fragment identifier considerations: The fragment identifier notation and semantics for this media type are the same as for application/xml, as specified in Section 5 in [RFC 7303].
>
> 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): Same as for application/xml [RFC 7303]
>     3. File extension(s): N/A
>     4. Macintosh file type code: N/A
>     5. Object Identifiers: N/A
>
> General Comments: This media type identifies a meta-format that encompasses all XML-based formats which are identified by a particular name of the root element, optionally together with a namespace URI or the PUBLIC identifier stored in the DTD. It it intended for use in applications that describe files using media types, but do not have sufficient heuristics to output a more specific media type. In such a case, the application may parse the XML and use the name of the root element and the DTD to populate the "root", "ns", and "public" parameters.
>
> Examples:
> application/prs.implied-document+xml;root=svg;ns="http://www.w3.org/2000/svg";public="-//W3C//DTD SVG 1.1//EN" - The media type that may represent a valid SVG image or other XML documents with the same properties.
>
> Person to contact for further information:
>
>     1. Name: Marek Čermák
>     2. Email: [e-mail]
>
> Intended usage: LIMITED USE
>
> It is not recommended to use this media type when a more concrete type is known. Its use beyond automated archival, content negotiation and other purposes in general file hosting is limited. Applications should not advocate themselves as accepting this media type if they require more specific structure or format.
>
> Author/Change controller: Marek Čermák <[e-mail]>
>
> On Fri Mar 17 23:15:13 2023, amanda.baber wrote:
>> Hi Alexey,
>>
>> This is #3 of 3.
>>
>> thanks,
>> Amanda
>>
>> =====
>>
>> Name: Marek Čermák
>>
>> Email: [e-mail]
>>
>> Media type name: application
>>
>> Media subtype name: prs.implied-document+xml
>>
>> Required parameters: root: The local name of the root element in the
>> XML document.
>>
>> Optional parameters: ns: The namespace URI of the root element, if
>> specified.
>> public: The PUBLIC identifier in the DTD, if provided.
>> charset: The character set used by the document, with the same syntax
>> and semantics as for application/xml [RFC 7303].
>>
>> Encoding considerations: binary
>>
>> Same as for application/xml [RFC 7303].
>>
>> Security considerations: Same as for application/xml [RFC 7303]. When
>> processing this type, applications MUST ensure that the structure of
>> the file matches "root", "ns" and "public", and if they intend to
>> assign a more concrete media type to the file, they SHOULD verify that
>> it is valid. Applications MUST NOT open files coming from untrusted
>> sources if it could lead to arbitrary code execution.
>>
>> Interoperability considerations: Applications that accept or produce
>> this type should not be assumed to have knowledge of more than the
>> root element namespace and local name, and the PUBLIC identifier. It
>> is not guaranteed that an application offering this type will produce
>> a file in a format that is most commonly associated with parameters,
>> and it is not guaranteed that an application accepting this type will
>> be able to process it any of the formats associated with the
>> parameters.
>>
>> Published specification: N/A
>>
>> Applications which use this media: This media type is intended for
>> applications that have to guess the media type of a file, but do not
>> contain heuristics that allow to pick a more concrete media type with
>> acceptable confidence.
>>
>> Fragment identifier considerations: N/A
>>
>> 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): Same as for application/xml [RFC 7303]
>> 3. File extension(s): N/A
>> 4. Macintosh file type code: N/A
>> 5. Object Identifiers: N/A
>>
>> General Comments: This media type identifies a meta-format that
>> encompasses all XML-based formats which are identified by a particular
>> name of the root element, optionally together with a namespace URI or
>> the PUBLIC identifier stored in the DTD. It it intended for use in
>> applications that describe files using media types, but do not have
>> sufficient heuristics to output a more specific media type. In such a
>> case, the application may parse the XML and use the name of the root
>> element and the DTD to populate the "root", "ns", and "public"
>> parameters.
>>
>> Examples:
>> application/prs.implied-
>> document+xml;root=svg;ns="http://www.w3.org/2000/svg";public="-
>> //W3C//DTD SVG 1.1//EN" - An executable file using the "sh -r" command
>> to interpret it, such as Shell scripts using the shebang sequence.
>>
>> Person to contact for further information:
>>
>> 1. Name: Marek Čermák
>> 2. Email: [e-mail]
>>
>> Intended usage: LIMITED USE
>>
>> It is not recommended to use this media type when a more concrete type
>> is known. Its use beyond automated archival, content negotiation and
>> other purposes in general file hosting is limited. Applications should
>> not advocate themselves as accepting this media type if they require
>> more specific structure or format.
>>
>> Author/Change controller: Marek Čermák <[e-mail]>