Fyi: [IANA #1186601] Request for media type application/rif+xml

Sandro noted that we never registered the media type for RIF, so I
submitted a request 2 weeks ago and received the following feedback.
I believe the next step would be to produce a revision of the REC that
includes the feedback. Unless I'm mistaken, we should be able to do so
through editorial changes:
 https://www.w3.org/2020/Process-20200915/#revised-rec-editorial

I included for reference the template that I submitted at the end.

Is there anyone interested in working with me to help answer questions
and provide a revision?

Philippe

======== IETF review =============================

First and foremost, this registration refers to RFC 3023 throughout. RFC
3023
is obsolete; the current XML registration specification is RFC 7303. All of
the references need to be updated accordingly.

> Name: Philippe Le Hegaret
> Email: plh@w3.org

> Media type name: application
> Media subtype name: rif+xml

> Required parameters: none

> Optional parameters:
> charset, as per RFC 3023 (XML Media Types)

This should reference section 3 of RFC 7303 specifically. Please also
take note
of the guidance in section 4.2, in particular that if this media type
doesn't
need a charset parameters it's best not to define one.

> Encoding considerations: 8bit
> same as RFC 3023 (XML Media Types)

This implies that charsets such as UTF-16 variants are never used. Are
you sure this is what you want? I don't see any charset restrictions in
the specification.

> Security considerations:

> Systems which consume RIF documents are potentially vulnerable
> to attack by malicious producers of RIF documents. The
> vulnerabilities and forms of attack are similar to those of
> other Web-based formats with programming or scripting
> capabilities, such as HTML with embedded Javascript.

> Excessive Resource Use / Denial of Service Attacks

> Complete processing of a RIF document, even a conformant
> RIF Core document, may require arbitrarily great CPU and
> memory resources. Through the use of "import", processing
> may also require arbitrary URI dereferencing, which may
> consume all available network resources on the consuming
> system or other systems. RIF consuming systems SHOULD
> implement reasonable defenses against these attacks.

The use of capitalized words like "SHOULD" has no assigned meaning
in media type registrations; please use "should" instead.

> Exploiting Implementation Flaws

> RIF is a relatively complex format, and rule engines can be
> extremely sophisticated, so it is likely that some RIF
> consuming systems will have bugs which allow specially
> constructed RIF documents to perform inappropriate
> operations. We urge RIF implementors to make systems which
> carefully anticipate and handle all possible inputs,
> including those which present syntactic or semantic errors.

> External (Application) Functions

> Because RIF may be extended with local, application defined
> datatypes and functions, new vulnerabilities may be
> introduced. Before being installed on systems which consume
> untrusted RIF documents, these external functions should be
> closely reviewed for their own vulnerabilities and for the
> vulnerabilities that may occur when they are used in
> unexpected combinations, like "cross-site scripting"
> attacks.

> In addition, as this media type uses the "+xml" convention, it
> shares the same security considerations as other XML formats;
> see RFC 3023 (XML Media Types).

These security considerations are very well done. The only thing that
needs to be added is some mention of integrity and confidentiality
protections. Simply saying that such protections may be needed and
if so can be provided externally would be sufficient.

> Interoperability considerations:

> This media type is intended to be shared with other RIF
> dialects, to be specified in the future. Interoperation
> between the dialects is governed by the RIF specifications.

> Published specification:

> https://www.w3.org/TR/2013/REC-rif-core-20130205/#Appendix:_RIF_Media_Type_Registration

Pointing at the registration template within the specification isn't
what's needed here, nor is it what appears in the registration form
within the specification itself:

RIF Core Dialect
W3C Working Draft (Recommendation Track)
http://www.w3.org/TR/rif-core/

RIF Datatypes and Builtins
W3C Working Draft (Recommendation Track)
http://www.w3.org/TR/rif-dtb/

RIF Basic Logic Dialect
W3C Working Draft (Recommendation Track)
http://www.w3.org/TR/rif-bld/

RIF Production Rule Dialect
W3C Working Draft (Recommendation Track)
http://www.w3.org/TR/rif-prd/

RIF Framework for Logic Dialects
W3C Working Draft (Recommendation Track)
http://www.w3.org/TR/rif-fld/

This media type is intended for use by all RIF dialects,
including those to be specified in the future. Identification
of the RIF dialect in use by a document is done by examining
the use of specific XML elements within the document.


> Applications which use this media:
> same as RFC 3023 (XML Media Types)

This doesn't really make sense, and once again what's in the
specification is better:

See: http://www.w3.org/2005/rules/wiki/Implementations

> Fragment identifier considerations:

> same as RFC 3023 (XML Media Types)

> Restrictions on usage:
> None

> Provisional registration? (standards tree only):
> (none)

> Additional information:

> 1. Deprecated alias names for this type: (none)
> 2. Magic number(s): same as RFC 3023 (XML Media Types)
> 3. File extension(s): .rif (or .xml)
> 4. Macintosh file type code: TEXT
> 5. Object Identifiers: (none)

> General Comments:

> Person to contact for further information:

> 1. Name: Sandro Hawke
> 2. Email: sandro@w3.org

> Intended usage: Common
> (empty)

> Author/Change controller: RIF is a product of the Rule Interchange Format (RIF) Working
> Group of the World Wide Web Consortium (W3C). See
> http://www.w3.org/2005/rules/wg for information on the group.
> The W3C (currently acting through this working group) has
> change control over the RIF specification.

============== end of IETF review ==============


==== registration template ===============

On Wed Jan 06 19:15:51 2021, plh@w3.org wrote:
>
> Name: Philippe Le Hegaret
> Email: plh@w3.org
>
> Media type name: application
> Media subtype name: rif+xml
>
> Required parameters: none
>
> Optional parameters:
> charset, as per RFC 3023 (XML Media Types)
>
> Encoding considerations: 8bit
> same as RFC 3023 (XML Media Types)
>
> Security considerations:
>        Systems which consume RIF documents are potentially vulnerable
>        to attack by malicious producers of RIF documents.  The
>        vulnerabilities and forms of attack are similar to those of
>        other Web-based formats with programming or scripting
>        capabilities, such as HTML with embedded Javascript.
>
> Excessive Resource Use / Denial of Service Attacks
>
> Complete processing of a RIF document, even a conformant
> RIF Core document, may require arbitrarily great CPU and
> memory resources.  Through the use of "import", processing
> may also require arbitrary URI dereferencing, which may
> consume all available network resources on the consuming
> system or other systems.  RIF consuming systems SHOULD
> implement reasonable defenses against these attacks.
>
> Exploiting Implementation Flaws
>
> RIF is a relatively complex format, and rule engines can be
> extremely sophisticated, so it is likely that some RIF
> consuming systems will have bugs which allow specially
> constructed RIF documents to perform inappropriate
> operations. We urge RIF implementors to make systems which
> carefully anticipate and handle all possible inputs,
> including those which present syntactic or semantic errors.
>
> External (Application) Functions
>
> Because RIF may be extended with local, application defined
> datatypes and functions, new vulnerabilities may be
> introduced.  Before being installed on systems which consume
> untrusted RIF documents, these external functions should be
> closely reviewed for their own vulnerabilities and for the
> vulnerabilities that may occur when they are used in
> unexpected combinations, like "cross-site scripting"
> attacks.
>
> In addition, as this media type uses the "+xml" convention, it
> shares the same security considerations as other XML formats;
> see RFC 3023 (XML Media Types).
>
> Interoperability considerations:
>        This media type is intended to be shared with other RIF
>        dialects, to be specified in the future.  Interoperation
>        between the dialects is governed by the RIF specifications.
>
> Published specification:
> https://www.w3.org/TR/2013/REC-rif-core-
> 20130205/#Appendix:_RIF_Media_Type_Registration
>
>
> Applications which use this media:
> same as RFC 3023 (XML Media Types)
>
>
>
> Fragment identifier considerations:
> same as RFC 3023 (XML Media Types)
>
> Restrictions on usage:
> None
>
> Provisional registration? (standards tree only):
> (none)
>
> Additional information:
>
> 1. Deprecated alias names for this type: (none)
> 2. Magic number(s): same as RFC 3023 (XML Media Types)
> 3. File extension(s): .rif (or .xml)
> 4. Macintosh file type code: TEXT
> 5. Object Identifiers: (none)
>
> General Comments:
>
>
> Person to contact for further information:
>
> 1. Name: Sandro Hawke
> 2. Email: sandro@w3.org
>
> Intended usage: Common
> (empty)
>
> Author/Change controller: RIF is a product of the Rule Interchange
> Format (RIF) Working
>        Group of the World Wide Web Consortium (W3C).  See
>        http://www.w3.org/2005/rules/wg for information on the group.
>        The W3C (currently acting through this working group) has
>        change control over the RIF specification.

Received on Tuesday, 19 January 2021 14:17:26 UTC